DSpace, LAMS, Mahara and OpenSim install on CentOS

2009-06-25T04:21:00.001-07:00

There are five blogs in this series.

Please select the link below as required:-

DSpace Install Blog

LAMS Install Blog

Mahara Install Blog

OpenSim Install Blog

Server Syncronisation Blog

Mirroring non identical servers using rsync

2009-06-10T22:26:00.001-07:00

I wrote this blog after spending some time learning how to synchronise the software build between two servers with different hardware architectures (including different drive partitioning) but both running the same version of CentOS Linux.

As part of upgrading our VLE servers found a need to mirror software builds on servers. These servers run CentOS 5, DSpace, LAMS, Mahara and Moodle.

Looking on the Web for rsync scripts with lists of files to exclude the main message I got was "Don't do it, it can't be done". This blog explains how it can be done very successfully;)

We had two servers standbyvle and vle and I wanted to create a copy of the software build on standbyvle onto vle. In this case it was not just a hot backup exercise as the hostname and hardware configuraton of each server was different.

The standbyvle server was already running DSpace, LAMS, Mahara and Moodle. I wanted to save myself the trouble of re-installing these applications and their associated data on the new server.

General Synchronisation Issues

The first step was to perform a complete install of CentOS 5.3 on the vle server and get it up and running. After this is I ran yum update on both servers to make sure the OS software builds were as similar as possible. Both servers had "everything" installed on their package list. To be on the safe side I made sure both servers were booting from the same version of the kernel.

It was now a case of setting up the rsync server on the destination machine (vle). I edited /etc/rsyncd.conf on vle and used the following settings:

max connections = 10
log file = /var/log/rsync.log
timeout = 300
[root]
comment = Welcome to rsync on the vle server...
path = /
read only = no
list = yes
uid = root
gid = root
hosts allow = 10.100.0.22

Where 10.100.0.22 is the internal IP address of the standbyvle server

I then started the rsync process on vle as follows:

rsync --daemon

It was now a question of getting the rsync command on the source machine (standbyvle) right. The command line that worked for me was:

rsync -av --delete --exclude-from=/root/bin/excluded_standbyvle_vle / 10.100.0.20::root

Where 10.100.0.20 is the internal IP address of the vle server

The file /root/bin/excluded_standbyvle_vle contains the "magic" list of files to be excluded. These are largely machine specific (hardware/IP address/FQDN) and we do not want them copied over.

[root@standbyvle bin]# cat excluded_standbyvle_vle
/boot/
/dev/
/etc/cups/
/etc/fstab
/etc/hosts
/etc/ld.so.conf.d/
/etc/mail/sendmail.cf
/etc/modprobe.conf
/etc/modules.conf
/etc/mtab
/etc/ssh/
/etc/sysconfig/
/etc/X11/xorg.conf
/etc/xen/
/home/clive/.bashrc
/home/clive/.ssh/
/home/mysqlbackup/
/home/server_a/
/home/vleinternal/
/home/vletransfer/
/lib/modules/
/lost+found/
/media/
/mnt/
/proc/
/root/.bashrc
/root/.ssh/
/root/bin/backup
/sys/
/usr/src/kernels/
/var/cache/
/var/lib/ntp/
/var/lib/xen/
/var/lib/xenstored/
/var/lock/
/var/log/
/var/named/chroot/proc/
/var/run/
/var/spool/
/tmp/

On rebooting vle after synchronisation was complete it successfully came back up with the complete software build of standbyvle on it :D

The the root and dspace crontabs in /var/spool/cron were not copied over. These had to be copied over manually.

It was also necessary to configure sendmail to listen on port 25 of the vle servers IP address.

Note: To date (August 2009) I have temporarily disabled automatic kernel updates on the vle server as on a previous "test" run between a different pair of servers a yum kernel update broke the destination server boot process. I am going to use yum to manually update the kernel later in the year (College holidays!) and see if the server will still boot.

Getting Moodle Working

In order to get Moodle working on the new server it was necessary to edit moodle's config.php script and change the wwwroot directive to reflect the change in FQDN.

cd /home/vle0910user/moodle
nano config.php

Getting DSpace Working

In order to get DSpace working on the new server it was necessary to change every occurence of the old FQDN with the new FQDN in dspace.cfg (Next time I'll use sed as a search and replace tool as I missed several ocurrences first time round!)

nano /home/dspace/config/dspace.cfg

DSpace was then rebuilt and restarted as follows:

cd /home/dspace/dspace-1.5.2-src-release/dspace
mvn package
cd /home/dspace/dspace-1.5.2-src-release/dspace/target/dspace-1.5.2-build.dir
ant -Dconfig=/home/dspace/config/dspace.cfg update

su - root
service tomcat stop
service tomcat start

For some reason it was also necessary to restart tomcat and postgresql manually before all was well.

Gettings LAMS Working

As LAMS was already installed any subsequent configuration changes were made from an Admin login by following the following sequence of menus:

Sys Admin > Edit Configuration Settings > System Configuration

The Server URL parameter was changed to reflect the new FQDN and the changes saved. The firewire server running on 127.0.0.1 did not require any changes to its configuration settings.

It was also necessary to go to Sys Admin > Maintain Integrated Servers and create an entry for Moodle on the standbyvle server.

After saving the changes Moodle needed to be configured. From the Administration > Modules > Activities > LAMSv2 page the revised settings for the parameters server_url, server_id, server_key and request_source were entered. The connection with LAMS was then validated.

Getting Mahara Working

Moodle refused to integrate with Mahara due to the change in server URL but still keeping the old public key for Mahara, which is server specific. It is possible to tell Moodle to generate a new public key, but this is more difficult with Mahara. The only way of getting Mahara to generate a new key was to delete the openssl fields in the database, at which point Mahara then generates the new key.

I used phpPgAdmin to edit the Mahara database directly and deleted all records in the mahconfig table containing the following fields:

openssl_generations
openssl_history
openssl_keypair
openssl_keypair_expires

Mahara then automatically generated the ssl key and repopulated the table.

It was then just a matter of following the mahoodle documentation and the installation of Moodle on vle worked just fine with the installation of Mahara on vle :)

Setting up a Hot Backup Server

We have also moved our hot backup server (testvle) ino the DMZ and rebuilt it with CentOS 5. This machine has identical hardware to the vle server and can be brought up in an emergency as vle in the time it takes to reboot the machine.

The original process which this was based on can be found at the following blog:

http://www.linuxtraining.org.uk/blogger.html#twelve

The latest version of the backup script is shown below:

[root@vle bin]# cat backup
echo "Dspace anti-virus scan"
/usr/local/bin/clamscan --infected -r /home/dspace/assetstore
echo " "
service mysqld stop
service postgresql stop
rsync -av --delete --exclude-from=/root/bin/excluded_vle_testvle / 10.100.0.21::backup
rsync -av --delete /var/log/freshclam.log 10.100.0.21::backup/var/log
if test $(date | cut -c-3) = Sun
then
echo "Weekly backup"
service httpd stop
service tomcat stop
service handle stop
rsync -av --delete /home/dspace /home/backup/weekly
rsync -av --delete /home/vle0910 /home/backup/weekly
rsync -av --delete /home/vle0910user /home/backup/weekly
rsync -av --delete /var/lib/mysql/vle0910 /home/backup/weekly/mysql
rsync -av --delete /var/lib/pgsql/data /home/backup/weekly/pgsql
sleep 30
service httpd start
service tomcat start
service handle start
fi
if test $(date | cut -c9-10) = 28
then
echo "Monthly backup"
sleep 30
service httpd stop
service tomcat stop
service handle stop
rsync -av --delete /home/dspace /home/backup/monthly
rsync -av --delete /home/vle0910 /home/backup/monthly
rsync -av --delete /home/vle0910user /home/backup/monthly
rsync -av --delete /var/lib/mysql/vle0910 /home/backup/monthly/mysql
rsync -av --delete /var/lib/pgsql/data /home/backup/monthly/pgsql
sleep 30
service httpd start
service tomcat start
service handle start
fi
service postgresql start
service mysqld start

The excluded file list is shown below:

[root@vle bin]# cat excluded_vle_testvle
/dev/pts/
/dev/.udev/
/etc/cron.hourly/virusscan
/etc/cron.weekly/dspace
/etc/cups/
/etc/hosts
/etc/mail/sendmail.cf
/etc/rc.d/rc.local
/etc/rsyncd.conf
/etc/sysconfig/network
/etc/sysconfig/network-scripts/
/home/backup/
/home/clive/.bashrc
/media/
/proc/
/root/.bashrc
/root/bin/backup
/selinux/
/sys/
/var/lib/mrtg/mrtg.ok
/var/lib/ntp/
/var/lib/slocate/
/var/lib/slocate/slocate.db
/var/lock/
/var/log/
/var/named/chroot/proc/
/var/run/
/var/spool/clientmqueue/
/var/spool/cron/dspace
/var/spool/cron/root
/var/spool/mail/
/var/spool/mqueue/

Server Synchronisation Blog

DSpace, LAMS, Mahara and OpenSim install on CentOS

Mirroring non identical servers using rsync