« July 2010 | Main | October 2010 »

September 22, 2010

Configure backup of Contao sites on OIALinux server

Intro

My last few posts covered working with OIALinux server and moving Contao CMS managed websites from our unit's webserver to OIT hosted server. Next step is to set up backup of Contao websites. There are two distinct items that are necessary to back up:

  • Files that make up Contao sites
  • MySQL database that stores some the data about Contao hosted sites

By default all files in /swadm directory are backed up nightly with 30 retention period. This is done automatically without you needing to do anything.

In order to backup up MySQL however it is necessary to make regular "dumps" of the contao database so that those could be backed up.

Configure MySQL backup

From past experience I knew that configuring regular backups of MySQL can be tricky. I searched the web for the scripts that would do this for me and found AutoMySQLBackup sript. This seemed to do exactly what I needed and was easy enough to set up.

I followed the installation instruction on the AutoMySQLBackup sript page with an exception of the step 5 where you asked to place the script in /etc/cron.daily. Since swadm user doesn't have rights to /etc/cron.daily, I needed to set up crontab for swadm and configure an entry in crontab to run AutoMySQLBackup.

I found a good writeup on setting up crontab. By using this guide I set up crontab and placed an entry to run AutoMySQLBackup every day.

With MySQL dumps created and placed into /swadm/backup directory and automatic backup of all files in /swadm directory, the websites hosted by Contao are backed up.

September 21, 2010

Moving sites hosted with Contao CMS to OIALinux server

Background

We currently host 4 websites with a single install of Contao CMS. This installation of Contao was hosted from our own unit's Linux server. This article covers how I moved the four websites from our unit's server to OIT hosted Linux server. Many pointers on how to move the Contao sits were taken from the Contao documentation.

The move can be broken down into 7 steps:

  1. Create domain aliases
  2. Confige Apache httpd.conf file virtual host
  3. Copy over the files
  4. Change file ownership
  5. Copy the database
  6. Run the Contao install tool
  7. Configure the websites in Contao backend

1. Create domain aliases

Let's say that we had websites with following URLs:
  • siteA.unitname.umn.edu
  • siteB.unitname.umn.edu
  • siteC.unitname.umn.edu
  • siteD.unitname.umn.edu

I wanted to bring up the websites on the new server with different URLs. This would allow me to troubleshoot any problems with them and reduce the downtime to the production URLs. To do this, I requested 4 new DNS aliases to be assigned to the OIA Linux server from OIT Networking Services. Let's call these aliases:

  • siteA2.unitname.umn.edu
  • siteB2.unitname.umn.edu
  • siteC2.unitname.umn.edu
  • siteD2.unitname.umn.edu

Now I have URLs for my 4 websites that are all pointing to the new server.

2. Confige Apache httpd.conf file virtual host

In order to direct these aliases to correct location on the server I configured Apache to use Name Based virtual hosts. Since all four websites are hosted with Contao, I need to create one virtual host directive for the main server URL (name.unitname.umn.edu) and second virtual host directive for the 4 sites that are served with Contao.

NameVirtualHost *:80

<VirtualHost *:80>
ServerName name.unitname.umn.edu
DocumentRoot /swadm/web
<Directory /swadm/web>
allow from all
Options +Indexes
</Directory>
</VirtualHost>

<VirtualHost *:80>
DocumentRoot /swadm/web/contaosites
<Directory /swadm/web/contaosites>
AllowOverride All
Options Indexes FollowSymLinks
Order allow,deny
Allow from all
</Directory>
ServerName siteA2.unitname.umn.edu
ServerAlias siteB2.unitname.umn.edu siteC2.unitname.umn.edu siteD2.unitname.umn.edu
</VirtualHost>

3. Copy over the files

Next, I created a compressed file of all files and directories of contaosites folder on the old server. This is where all the files are stored that make up the four websites. I copied the compressed file to the new server and uncompressed into /swadm/web/contaosites folder.

4. Change file ownership

In order for the Contao CMS application to work all files and folder have to be owned by the user account that is used by Apache webserver. On the old server which ran Ubuntu Linux, this account was www-data. On the new server which is Red Hat, the Apache runs under a user account called apache. Changing file ownership is something that swadm user account is not allowed to do. I send an email to oialinux at umn dot edu asking them to make this change.

5. Copy the database

Created a mysql dump file (mysqldum -B contaodb) of the Contao database and imported it into the mysql database ( mysql database < contaodb.sql) on the new server. I used this MySQL tutorial for the syntax.

6. Run the Contao install tool

Next I accessed http://name.unitname.umn.edu/contaosites/contao/install.php and logged in with the install tool username and password that I had used for my initial Contao installation on the old server. The installation tool allowed me to enter my database username and password to be used by Contao CMS.

7. Configure the websites in Contao backend

Once I had configured the database connection, I could access Contao backend by going to http://name.unitname.umn.edu/contaosites/contao with my browser and log in. Once logged in I navigated to Site Structure and changed the site website root DNS for each for the site to use the new aliases.

With this all 4 websites are active with new URLs. Once I have verified that everything works properly, I can transfer the correct site URLs to the new server.

September 20, 2010

Prepping OIALinux server for Contao CMS

Contao CMS system requirements

Contao CMS requires three items for hosting:

  • Php version 5
  • Apache web server
  • MySQL database server

OIALinux server currently comes with

  • php-5.1.6
  • apache 2.2.3
  • mysql-5.0.77

All software is installed, but it needs to be configure to work so that swadm user can administer it.

Configure Apache

Apache is installed into /swadm/etc/httpd directory. However the DocumentRoot directive in httpd.conf file needs to be edited to point to a directory in /swadm space. So first, I created a new directory called web in /swadm directory. Then I edited the httpd.conf file DocumentRoot directive to point to /swadm/web .

To test my configuration I placed a file called index.html in /swadm/web and started Apache (sudo /etc/services httpd start). Then I navigated to the server URL to see if I can see the contents of the index. html file.

Configure MySQL

MySQL server is installed, but it is not configured yet. To begin configuring MySQL:

  1. First become a swadm user:
    sudo su - swadm
  2. now we need to create a directory for MySQL databases:
    mkdir /swadm/mysql
  3. Next we change the datadir value in /etc/my.cnf to point to the MySQL database directory
    sudoedit /etc/my.cnf and change the datadir value with the text editor
  4. Next we launch the MySQL service
    sudo /etc/service mysqld start
  5. Since this was the first time starting MySQL it prompted me to choose if I wanted to run a secure installation. I chose yes. The wizard configured the system database and prompted me for a MySQL root password. Now we have a working instance of MySQL.

Create a new user and database for Contao CMS

Once we have a working MySQL service we can proceed to create a user account and database for storing Contao CMS information. I used this MySQL administration guide to help me with this task.

First, I created a new database:
mysqladmin -h localhost -u root -p create bedrock
Next, I created a new user and gave it permission to the database:

[prompt]$ mysql -h localhost -u root -ppassword
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 3.23.41

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> USE mysql;
mysql> SHOW TABLES;
+-----------------+
| Tables_in_mysql |
+-----------------+
| columns_priv |
| db |
| func |
| host |
| tables_priv |
| user |
+-----------------+
mysql> INSERT INTO user (Host, User, Password, Select_priv) VALUES ('', 'Dude1', password('supersecret'), 'Y');
mysql> FLUSH PRIVILEGES; - Required each time one makes a change to the GRANT table
mysql> GRANT ALL PRIVILEGES ON bedrock.* TO Dude1;
mysql> FLUSH PRIVILEGES; - Required each time one makes a change to the GRANT table
mysql> quit

Now we have a user account and a database that we can use for Contao CMS.

Install a Php plugin

Contao requires two additional extensions to be installed and enabled in PHP:
  • mbstring
  • SOAP

To enable these, send an email to oialinux at umn.edu and ask them to install it for you.

Now our environment is set up to install Contao.

Logging into OIALinux server

Background

This last summer UMN OIT began offering a new hosted server service. The service provides units with a virtual server (either Red Hat Linux or Windows 2003 server) upon a request from the unit director. We (Disability Services) began using this service about a month ago. We are using the OIALinux server for hosting our websites. This article talks about how to log into OIALinux server and is meant primarily for server administrators and website developers.

OIALinux server does not provide any kind of Graphical User Interface (GUI) access, rather you use an SSH client (Putty) software to log into the server and administer it. There are two ways on how you can log in:

  1. First creating a VPN connection and then SSH into the server (let's call it VPN connection)
  2. First SSH into a gateway server (ale.oit.umn.edu or ale2.oit.umn.edu) and then from there SSH into your server (non-VPN connection).

In both cases you would need to use MKey + Pin for your password.

Let's take a more detailed look at how the login works.

VPN connection

For creating a VPN connection you would first need to install VPN IPSec software that is made available from the OIT website. Once installed you need to add a customer vpn profile.pcf. You would need to download and copy that file into C:\Program Files\Cisco Systems\VPN Client\Profiles directory. Once there, you can start a new VPN connection and log in with your Internet username and MKey + Pin for a password. After creating the VPN connection, you can launch Putty from desktop and SSH into your server again authenticating with your Internet ID and MKey + Pin as password.

Non VPN connection

For creating a non-VPN connection, you would launch Putty and SSH into ale.oit.umn.edu or ale2.oit.umn.edu. Once logged in, you would enter the command SSH yourservername and SSH into your server. Both of these connections are created by using your Internet ID and MKey+PIN for password.

I find that first creating a VPN connection and then SSH into a server is easier and provides an additional benefit of being able to use a Secure FTP client such as WINSCP to view the server directory structure, file permissions, and file content.

Brief description on user permissions on the server

Once on the server you may notice that you do not have permissions to do much. Try issuing a command sudo -l as your user account to see what you can do. There is another account on the server (swadm) that has more administrative permmission to the server. To work as a swadm user, issue a command sudo su - swadm .

September 2, 2010

Explorations into UMN Shibboleth Auth - Part 4 Configuring Shibboleth SP to use UMN test IdP

Recap

So far I have configured my Shibboleth SP to use the TestShib2 service. Using the TestShib2 service is relatively simple as it does not require that you edit the shibboleth2.xml file. The shibboleth2.xml file is provided to you by the service and you can simply copy the file into the correct location and restart the shibd service in order to use it. The shibboleth2.xml file includes an external reference to the metadata.xml file that simplifies its use even more because there is no need to copy the metadata.xml locally and reference it from shibboleth2.xml file.

Steps required for using UMN test Idp

  1. Save a copy of the local computers metadata .xml file by going to http://yourURL/Shibboleth.sso/Metadata. This needs to be sent to idm at umn dot edu along with your request
  2. Send an email to idm at umn dot edu requesting that your server be added to the list of authorized servers for the UMN test IdP.
  3. Request that your username would be added to the user list who are autherized to use the test IdP for authentication.
  4. Download the copy of the test IdP metadata file from UMN Shibboleth wiki and place it in /etc/shibboleth directory on your server.
  5. Configure your server's /etc/shibboleth/shibboleth2.xml file to reference UMN test IdP and the test IdP metadata file.
  6. If you want to protect https space instead of http space, then you need to request that change by emailing idm at umn dot edu.

Configuring shibboleth2.xml file to work with UMN test IdP

The trickiest part of configuring Shibboleth in my view is in configuring the shibboleth2.xml file on your server. This file controls how Shibboleth will behave and what it will try to protect. In this case we are simply protecting a web directory. It is best to start with shibboleth2.xml file that came with the distribution. There are four aspects of that file that need to be changed:
  1. MetadataProvider - This needs to point to the local or remote metadata file
  2. RequestMap - the type and in the case of Native a host name and path of the directory being protected
  3. The right entityID - This is just a name that you give your own server's entity (ie. https://yourURL/shibboleth-sp this does not need to resolve to anything
  4. SessionInitiator - Here you indicate where to relay session requests (in our case this is the UMN test IdP URL

Linked below is a shibboleth2.xml file that is configured to work with UMN Test IdP.
shibboleth2_UMN_TestIdP.xml