DSpace installation on Fedora Core and CentOS (RHEL)

tag:blogger.com,1999:blog-111798432008-08-13T05:34:46.680-07:00DSpace installation on Fedora Core and CentOS (RHEL)clivehttp://www.blogger.com/profile/04834932543873462481noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-11179843.post-1109753919949191552005-03-02T00:56:00.000-08:002008-08-13T05:34:46.731-07:00DSpace installation procedure on Fedora Core 3 and CentOS 4 (RHEL 4)Written by Clive Gould. (To contact Clive please use this <a href="http://ce.bromley.ac.uk/linux/booking.htm">messages</a> form. Our Linux training website can be reached by clicking <a href="http://ce.bromley.ac.uk/linux">here</a>) <a name="menu"></a>Menu 1) <a href="#one">DSpace 1.2.1 installation procedure</a> 2) <a href="#two">Handle Server installation procedure</a> 3) <a href="#three">phpPgAdmin installation and configuration</a> 4) <a href="#four">Getting Apache to talk to Tomcat using mod_jk2</a> 5) <a href="#five">Starting DSpace Automatically</a> 6) <a href="#six">Managing DSpace, Tomcat and Handle Server logs</a> 7) <a href="#seven">Making DSpace available via Apache and HTTPS</a> 8) <a href="#eight">Changing the contact telephone number</a> 9) <a href="#nine">Upgrading to Tomcat 5.5</a> 10) <a href="#ten">Upgrading to DSpace 1.2.2</a> 11) <a href="#eleven">Customising the Web User Interface</a> 12) <a href="#twelve">Virus scanning and establishing a hot backup server</a> 13) <a href="#thirteen">Upgrading to DSpace 1.3.1</a> 14) <a href="#fourteen">Getting statistics working</a> 15) <a href="#fifteen">Modified handle server configuration</a> 16) <a href="#sixteen">Upgrading to DSpace 1.3.2</a> 17) <a href="#seventeen">Providing OAI access to DSpace</a> 18) <a href="#eighteen">Using a commercial wildcard SSL certificate</a> 19) <a href="http://www.linuxtraining.org.uk/blogger1.html">Installing LAMS on the same server as DSpace</a> 20) <a href="#twenty">Upgrading to DSpace 1.4 (failed)</a> 21) <a href="#twentyone">Re-installing DSpace 1.4 (success)</a> 22) <a href="#twentytwo">Upgrading the handle server to version 6.2</a> 23) <a href="#twentythree">Upgrading to DSpace 1.4.1</a> 24) <a href="#twentyfour">Upgrading to DSpace 1.4.2</a> 25) <a href="#twentyfive">Enabling RADIUS Authentication in DSpace 1.4.2</a> 26) <a href="#twentysix">Using a commercial host specific SSL certificate</a> 27) <a href="#twentyseven">Upgrading to DSpace 1.5.0</a> <a name="one"></a>1) DSpace 1.2.1 installation procedure This blog covers DSpace installation on two separate platforms: a) 1.2.1 (subsequently upgraded to 1.2.2) on Fedora Core 3, which I first set up in March 2005. b) 1.2.2 (subsequently upgraded to 1.3.2) on CentOS 4, which I first set up in July 2005. The machine I used for the Fedora Core 3 installation was an existing, fully Internet accessible server providing services to staff and students 24x7. It was already running apache, vsftpd, sshd, named, dovecot and mysqld. The machine I used for the CentOS 4 installation was a new high specification server and I installed jdk-1_5_0_04, apache-ant-1.6.5 and jakarta-tomcat-5.5.9 on it following the instructions given for DSpace 1.2.1 and Fedora Core 3 in this blog. I have added comments in blue where the CentOS installation differed from the earlier Fedora Core 3 installation of DSpace. Beginning the Fedora Core 3 installation: The JDK (1.5.0) had already been downloaded from Sun and installed in /usr/java/jdk1.5.0 - I subsequently renamed the directory jdk1.5.0 to jdk in order to simplify paths in the event of a future upgrade of the JDK. The next step was to download Ant (1.6.2) and install it. I installed it as root in /usr/local as follows: cd /usr/local lynx http://ant.apache.org/bindownload.cgi tar -xzvf apache*.tar.gz mv apache-ant-1.6.2 ant As Apache was already running and in use I initially decided to install Tomcat as a totally separate and independent installation. The next step was to create a user dspace with home directory /home/dspace. As user dspace I then proceded to download and install Tomcat (4.1.31) in /home/dspace as follows: cd /home/dspace lynx http://jakarta.apache.org/site/downloads/downloads_tomcat-4.cgi tar -xzvf jakarta-tomcat-4.1.31.tar.gz mv jakarta-tomcat-4.1.31 tomcat The following paths were set up in /etc/profile: export JAVA_HOME=/usr/java/jdk export CATALINA_HOME=/home/dspace/tomcat export ANT_HOME=/usr/local/ant export PATH=${PATH}:${ANT_HOME}/bin export PATH=${PATH}:${JAVA_HOME}/jre/bin As user dspace I started Tomcat from the /home/dspace/tomcat/bin directory using the following command: [dspace@cd bin]$ ./startup.sh Using CATALINA_BASE: /home/dspace/tomcat Using CATALINA_HOME: /home/dspace/tomcat Using CATALINA_TMPDIR: /home/dspace/tomcat/temp Using JAVA_HOME: /usr/java/jdk Running nmap on the IP address of the machine confirmed that Tomcat was running and listening for connections on port 8080: 8080/tcp open http-proxy Visting the URL http://cd.bromley.ac.uk:8080 allowed me to try out the jsp examples available from the Tomcat homepage :-) As user dspace I then downloaded DSpace and installed it in the home directory of the dspace user /home/dspace as follows: cd /home/dspace lynx http://sourceforge.net/projects/dspace/ gunzip -c dspace-1.2.1-source.tar.gz tar -xf - The next task as user dspace was to download the pg74.215.jdbc3.jar file which was specific to the version of the JDK (1.5.0) and the version of PostgreSQL (7.4.7-3) I was using: cd /home/dspace/dspace-1.2.1-source/lib lynx http://jdbc.postgresql.org/download.html#jars The next task was getting PostgreSQL working. PostgreSQL was already installed with Fedora Core 3. The first step was to become user postgres from a root login by using the command: su - postgres The postgres user has administrative control over PostgreSQL and commands typed by this user can be used to administer the database directly. The first step was to create a new Postgres database installation using the following command: initdb -D /var/lib/pgsql/data The next step was to edit the file /var/lib/pgsql/data/postgresql.conf and change the tcpip parameter to true as shown below: tcpip_socket = true The next step was to edit the file /var/lib/pgsql/data/pg_hba.conf and comment out the following line at the end of the file: # local all all ident sameuser I then appended the following lines to the end of the file: host dspace dspace 127.0.0.1 255.255.255.255 md5 local template1 postgres trust local template1 dspace trust I then had to become root and start PostgreSQL as follows: [root@cd data]# /etc/init.d/postgresql start Starting postgresql service: [ OK ] It was then necessary to su - postgres and create the user dspace and the database dspace as follows: -bash-3.00$ createuser -U postgres -d -A -P dspace Enter password for new user: Enter it again: CREATE USER -bash-3.00$ createdb -U dspace -E UNICODE dspace CREATE DATABASE As user dspace it was then necessary to edit the file /home/dspace/dspace-1.2.1-source/config/dspace.cfg and add the appropriate entries, paying particular attention to changing ALL the paths from /dspace/ to /home/dspace/ The following website proved most helpful with this: <a href="http://www.thesesalive.ac.uk/archive/DSpaceInstall.pdf">http://www.thesesalive.ac.uk/archive/DSpaceInstall.pdf</a> Before running ant to build dspace it was necessary to remove a number of rpm's that had been installed as part of the default Fedora Core 3 upgrade of everything: [root@cd ~]# rpm -e --nodeps libgcj gcc-java libgcj-devel gettext ant tomcat (If this is not done you will get cryptic error messages such as: BUILD FAILED file:/home/dspace/dspace-1.2.1-source/build.xml:109: Error running gcj34 compiler) Note: With CentOS 4 it was not necessary to remove any of these rpms. As user dspace the application was now successfully built using the commands: [dspace@cd dspace-1.2.1-source]$ ant [dspace@cd dspace-1.2.1-source]$ ant fresh_install I successfully copied over the .war files to tomcat webapps directory as shown below and DSpace ran. cd /home/dspace/dspace-1.2.1-source/build/ cp *.war /home/dspace/tomcat/webapps I ran the following script to set up the administrator account: /home/dspace/bin/create-administrator Note: With CentOS 4 this produced a screen full of errors. The solution turned out to be correcting the path to Java. The last line of /home/dspace/bin/dsrun needed to be changed to: # Now invoke Java /usr/java/jdk/bin/java -mx2024m -classpath $FULLPATH "$@" This assumes that the jdk is installed in a directory called /usr/java/jdk For administrative purposes I tried setting up the posgres crontab to vacuum the database, but this did not work properly with my database access permissions. As a result the final crontab entry I set for user dsapce was as shown below: su - dspace [dspace@cd ~]$ crontab -l 0 1 * * * /home/dspace/bin/sub-daily # Run the media filter at 02:00 every day 0 2 * * * /home/dspace/bin/filter-media # Clean up the database nightly at 2.40am 40 2 * * * cd /home/dspace/vacuumdb && ( PGPASSWORD=`cat .pgpass` /usr/bin/vacuumdb --analyze -v -h 127.0.0.1 -U dspace dspace ) (When a user searches DSpace, both the metadata and indexed text are searched for matches, and the results are displayed together. Running the filter-media script regularly facilitates full-text searching for many text objects such as PDF, Word, HTML and text files.) In order to get database vaccuming to work properly, in addition to the final line in the crontab, I also created a directory /home/dspace/vacuumdb containing the file .pgpass (owned by user dspace and with 600 permissions), which in turn contained the database access password for the dspace database. I noticed that the text indexing wasn't working properly, unless I ran the script manually. Later on I came across several error messages in user dspace's email as follows: Subject: Cron dspace@cd /home/dspace/bin/filter-media Applying Media Filters /home/dspace/bin/dsrun: line 70: java: command not found Subject: Cron dspace@cd /home/dspace/bin/sub-daily /home/dspace/bin/dsrun: line 70: java: command not found It appeared that Cron could not find the path to java, so as user dspace, I added the following environment definition to the top of both the filter-media and sub-daily scripts: # Set Environment Variables (Added by Clive Gould on 1st April 2005) JAVA_HOME=/usr/java/jdk; export JAVA_HOME CATALINA_HOME=/home/dspace/tomcat; export CATALINA_HOME ANT_HOME=/usr/local/ant; export ANT_HOME PATH=${PATH}:${ANT_HOME}/bin PATH=${PATH}:${JAVA_HOME}/jre/bin; export PATH Cron subsequently ran the filter-media and sub-daily scripts correctly. Note: With CentOS 4 this environment variable definition was not necessary as the earlier alteration to the path for java in dsrun solved this problem. I then came across an error in my root emails containing the following text: # Send out subscription e-mails at 01:00 every dayException: java.io.IOException: /dspace/search not a directory at org.apache.lucene.sto/home/dspace/config/dspace.cfg re.FSDirectory.FSDirectory.java:154) It turned out that there were still some paths in dspace.cfg that required amendment. I edited /home/dspace/config/dspace.cfg and changed a few more paths from /dspace/ to /home/dspace I then ran the /home/dspace/bin/install-configs script to install my changes into the running dspace implementation. I was then able to run the /home/dspace/bin/index-all script successfully Had an error when creating my first collection when logged on as administrator to our new dspace website. The error was logged in /home/dspace/log/dspace.log as follows: java.lang.IllegalArgumentException: Not a directory: /home/dspace/upload As user dspace I created the directory /home/dspace/upload and from the browser deleted the community/collection I was trying to create. With CentOS 4 and DSpace 1.2.2 the upload directory was already present. This time I was able to successfully create a community and a collection. <a href="#menu">Return to Menu</a> <a name="two"></a>2) Handle Server installation procedure The procedure outlined below is the one I should have followed in order to configure the DSpace handle server on Fedora Core 3. (The process I actually followed was somewhat longer due to mistakes I made along the way!") This part of the blog covers the handle server configuration with DSpace 1.2.x. If you are configuring a handle server with DSpace 1.3.1 please read the last entry in this blog as well. The following websites really helped me with handle configuration: <a href="http://sunsite.utk.edu/diglib/dspace/">http://sunsite.utk.edu/diglib/dspace/</a> <a href="http://www.thesesalive.ac.uk/archive/ERAInstallation-1.9.html#_Toc82495072">http://www.thesesalive.ac.uk/archive/ERAInstallation-1.9.html#_Toc82495072</a> Configuration process: Log on as user dspace, move to the /home/dspace/bin directory and run the command shown below. Note that default responses provided by the command are shown in square brackets and where I have made replies other than the default they are shown in bold. The replies shown below are those that eventually proved the correct ones for my server, which is behind a NAT firewall blocking incoming UDP packets. In this case the IP address supplied was the internal IP address of the server on the Intranet side of the NAT box. [dspace@cd bin]$ dsrun net.handle.server.SimpleSetup /home/dspace/handle-server We will now configure your new Handle or Caching server. Please answer the following questions. Default answers, when available, will be shown in square brackets. Will this be a caching server or a regular handle server? (If unsure, choose regular handle server) 1 - Handle server 2 - Caching handle server Please choose 1 or 2 and press enter: 1 Will this be a "primary" server (ie, not a mirror of another server)? (y/n) [y] Through what IP address will this server be accessible? (domain names are ok) 172.31.0.3 What port number will this server be listening to? [2641] What port number will the HTTP interface be listening to? [8000] Would you like to log all accesses to this server? (y/n) [n] y Each handle site has a version/serial number assigned to it. This is so that clients can tell if a particular site configuration has changed since the last time it accessed a server in the site. Every time you modify a site (by changing an IP address, port, or adding a server, etc), you should increment the version/serial number for that site Enter the version/serial number of this site: [1] Please enter a short description of this server/site: Bromley College Dspace Repository The Handle System can communicate via UDP and/or TCP sockets. Since UDP messages are blocked by many network firewalls, you may want to disable UDP services if you are behind such a firewall. Would you like to disable UDP services? (y/n) [n] y Server keys already exist, do you want to create new ones? (y/n) [n] Administrator keys already exist, do you want to create new ones? (y/n)[n] Generating site info record... ------------------------------------------------------- Congratulations, the configuration has been generated. The sitebndl.zip file contains the answers to the above questions and needs to be submitted to CNRI as the following excerpt from the DSpace install documentation (updated in August 2005) explains: "Go to to <a href="http://hdl.handle.net/4263537/5014">http://hdl.handle.net/4263537/5014</a> to upload the generated sitebndl.zip file. The upload page will ask you for your contact information. An administrator will then create the naming authority/prefix on the root service (known as the Global Handle Registry), and notify you when this has been completed. You will not be able to continue the handle server installation until you receive further information concerning your naming authority." (As our machine is behind a NAT firewall, I was additionally asked by CNRI to email them the external IP address of our server on the Internet side of the firewall. This was required to enable the CNRI handle server to talk to our local handle server. I received a reply within 24 hours containing our handle prefix, which was 2045) Edit /home/dspace/handle-servers/config.dct and change all three naming authority handles. (Note that the IP address within this file was the internal IP address of our server.) A copy of the final version of this file, which actually worked for me is shown below: [dspace@cd handle-server]$ cat config.dct { "hdl_http_config" = { "bind_address" = "172.31.0.3" "num_threads" = "15" "bind_port" = "8000" "backlog" = "5" "log_accesses" = "yes" } "hdl_udp_config" = { "bind_address" = "172.31.0.3" "num_threads" = "15" "bind_port" = "2641" "log_accesses" = "yes" } "hdl_tcp_config" = { "bind_address" = "172.31.0.3" "num_threads" = "15" "bind_port" = "2641" "backlog" = "5" "log_accesses" = "yes" } "server_type" = "server" "no_udp_resolution" = "n" "interfaces" = ( "hdl_udp" "hdl_tcp" "hdl_http" ) "server_config" = { "server_admins" = ( "300:0.NA/2045" ) "replication_admins" = ( "300:0.NA/2045" ) "this_server_id" = "1" "max_session_time" = "86400000" "max_auth_time" = "60000" "backup_admins" = ( "300:0.NA/2045" ) "case_sensitive" = "no" "storage_type" = "CUSTOM" "storage_class" = "org.dspace.handle.HandlePlugin" } } With DSpace 1.2.2 and CentOS 4 the default config.dct file did not work properly and the handle server would not correctly resolve. I had to replace the default config.dct with a "cut and paste" of the above file with the IP address updated to reflect the new server. On restarting the handle server all was well :-) Edit /home/dspace/config/dspace.cfg as follows to tell DSpace to allocate handles beginning with your prefix. A excerpt from our file is shown below: ##### Handle settings ###### # CNRI Handle prefix handle.prefix = 2045 # Directory for installing Handle server files handle.dir = /home/dspace/handle-server Before the new handle prefix settings will take effect in DSpace it is necessary to restart Tomcat using the scripts in the /home/dspace/tomcat/bin directory: [dspace@cd bin]$ ./shutdown.sh Using CATALINA_BASE: /home/dspace/tomcat Using CATALINA_HOME: /home/dspace/tomcat Using CATALINA_TMPDIR: /home/dspace/tomcat/temp Using JAVA_HOME: /usr/java/jdk [dspace@cd bin]$ ./startup.sh Using CATALINA_BASE: /home/dspace/tomcat Using CATALINA_HOME: /home/dspace/tomcat Using CATALINA_TMPDIR: /home/dspace/tomcat/temp Using JAVA_HOME: /usr/java/jdk At this point upload a file into your DSpace repository to test the handle allocation and check that DSpace is now allocating the correct handle prefix. Start the handle server from the /home/dspace/bin directory by running the command: [dspace@cd bin]$ ./start-handle-server If necessary, the local handle server can be stopped by killing the appropriate processes. This is illustrated in the excerpt shown below: [dspace@cd ~]$ ps aux dspace 29190 0.0 0.0 4332 1004 ? S Mar13 0:00 /bin/sh ./dsrun -Dlog4j.configuration=log4j-handle-plugin.properties net.handle.server.Main /home/dspace/handle-se....... dspace 29196 0.0 2.3 497476 23828 ? Sl Mar13 0:01 java -Xmx256m -classpath :/home/dspace/lib/activation.jar:/home/dspace/lib/commons-cli.jar:/home/dspace/lib/common...... [dspace@cd ~]$ kill 29190 [dspace@cd ~]$ kill 29196 Useful tests for handle resolution include: 1) Using your browser to visit port 8000 on your handle server's IP address, which produces the homepage for your handle server. Entering a handle prefix (e.g. 0.NA/2045) will prove your handle server is communicating properly. 2) Visiting http://hdl.handle.net/ and entering one of your DSpace handles (e.g. 2045/39) should bring up the chosen resource page in DSpace or at least provide useful debugging information. Handle records log information in the following files: /home/dspace/handle-server/access.log /home/dspace/handle-server/error.log /home/dspace/log/handle-server.log (I had some problems because of the mistakes I'd made when providing my initial responses to the dsrun net.handle.server.SimpleSetup /home/dspace/handle-server command. Initially http://hdl.handle.net could not find my handle server as I'd only supplied the internal IP address and not the external one and chosen UDP instead of TCP for communications. The error message was "Error - Cannot Connect to Server The handle you requested cannot be found." Jane Euler of CNRI was really helpful and corrected this for me. I then found that my local handle server was not finding handles created in DSpace. The error message was "Nothing to display No URL value(s) found for the requested handle." This turned out to be due to my having run the above dsrun command line a second time, which of course regenerated config.dct and sitebndl.zip. Subsequently I had missed out on including the storage type and class lines at the end of config.dct the second time around!) <a href="#menu">Return to Menu</a> <a name="three"></a>3) phpPgAdmin installation and configuration I noticed that the new handles DSpace created once I had modified the handle prefix were correct, but the original handles created by Dspace before I got the handle server up & running and modified the prefix still remained at the original default value of 123456789. As a result of a newsgroup posting I decided to download and install phpPgAdmin. The idea was to use the web based administration tool for PostgreSQL to edit the dspace database directly and change the values of the default handle prefixes. I became the root user and used the following commands: cd /var/www/html lynx http://phppgadmin.sourceforge.net/?page=download tar -xzvf phpPgAdmin-3.5.2.tar.gz rm *.tar.gz cd phpPgAdmin cd conf cp config.inc.php-dist config.inc.php pico config.inc.php I modified config.inc.php as shown below in bold: [root@cd conf]# cat config.inc.php <?php /** * Central phpPgAdmin configuration. As a user you may modify the * settings here for your particular configuration. * * $Id: config.inc.php-dist,v 1.35.2.2 2005/02/11 11:23:39 chriskl Exp $ */ // An example server. Create as many of these as you wish, // indexed from zero upwards. // Display name for the server on the login screen $conf['servers'][0]['desc'] = 'PostgreSQL'; // Hostname or IP address for server. Use '' for UNIX domain socket. $conf['servers'][0]['host'] = '127.0.0.1'; // Database port on server (5432 is the PostgreSQL default) $conf['servers'][0]['port'] = 5432; // Change the default database only if you cannot connect to template1 $conf['servers'][0]['defaultdb'] = 'dspace'; // Specify the path to the database dump utilities for this server. // You can set these to '' if no dumper is available. $conf['servers'][0]['pg_dump_path'] = ''; $conf['servers'][0]['pg_dumpall_path'] = ''; // Example for a second server (PostgreSQL for Windows) //$conf['servers'][1]['desc'] = 'Test Server'; //$conf['servers'][1]['host'] = '127.0.0.1'; //$conf['servers'][1]['port'] = 5432; //$conf['servers'][1]['defaultdb'] = 'template1'; //$conf['servers'][1]['pg_dump_path'] = 'C:\\Program Files\\PostgreSQL\8.0\\bin\\pg_dump.exe'; //$conf['servers'][1]['pg_dumpall_path'] = 'C:\\Program Files\\PostgreSQ L\\8.0\\bin\\pg_dumpall.exe'; // Default language for the login screen if there's no translation // matching user's browser request. Eg: 'english', 'polish', etc. $conf['default_lang'] = 'english'; // If extra login security is true, then logins via phpPgAdmin with no // password or certain usernames (pgsql, postgres, root, administrator) // will be denied. Only set this false once you have read the FAQ and // understand how to change PostgreSQL's pg_hba.conf to enable // passworded local connections. $conf['extra_login_security'] = true; // Only show owned databases? // Note: This will simply hide other databases in the list - this does // not in any way prevent your users from seeing other database by // other means. (eg. Run 'SELECT * FROM pg_database' in the SQL area.) $conf['owned_only'] = false; // Display comments on objects? Comments are a good way of documenting // a database, but they do take up space in the interface. $conf['show_comments'] = true; // Display "advanced" objects? Setting this to true will show types, // operators conversions, languages and casts in phpPgAdmin. These // objects are rarely administered and can clutter the interface. $conf['show_advanced'] = false; // Display "system" objects? $conf['show_system'] = false; // Display reports feature? For this feature to work, you must // install the reports database as explained in the INSTALL file. $conf['show_reports'] = true; // Only show owned reports? // Note: This does not prevent people from accessing other reports by // other means. $conf['owned_reports_only'] = false; // Minimum length users can set their password to. $conf['min_password_length'] = 1; // Width of the left frame in pixels (object browser) $conf['left_width'] = 200; // Which look & feel theme to use $conf['theme'] = 'default'; // Show OIDs when browsing tables? $conf['show_oids'] = false; // Max rows to show on a page when browsing record sets $conf['max_rows'] = 30; // Max chars of each field to display by default in browse mode $conf['max_chars'] = 50; // Send XHTML headers? Unless debugging, it's best to leave this off $conf['use_xhtml'] = false; /***************************************** * Don't modify anything below this line * *****************************************/ $conf['version'] = 13; ?> I can now log on to phpPgAdmin from the browser as user dspace with the password I provided when I created the dspace user in PostgreSQL. The handle table can be found in phpPgAdmin at the following location: PostgreSQL?: dspace?: public?: handle?: It is simply a question of browsing this table and manually changing any pre-existant default handles of 123456789 to the handle prefix allocated by CNRI. DSpace happily picks up the new information and the handles can then be correctly resolved from hdl.handle.net <a href="#menu">Return to Menu</a> <a name="four"></a>4) Getting Apache to talk to Tomcat using mod_jk2 Tomcat and DSpace are now fully up and running on the cd server on port 8080 but we can only access them externally because our staff and student network proxy servers will only allow access via ports 80 and 443 to "external" servers! To get round this I have set up Apache to talk to Tomcat so that a URL in the format: http://cd.bromley.ac.uk/dspace automatically provides access to http://cd.bromley.ac.uk:8080/dspace The steps I took are outlined below: I found that Fedora Core 3 already had mod_jk2 installed as the excerpt below shows: [root@cd ~]# locate mod_jk2 /usr/lib/httpd/modules/mod_jk2.so I went to the /etc/httpd/conf.d directory and found that jk2.conf was already there: [root@cd conf.d]# cat jk2.conf # # Mod_jk2 allows the Apache Web server to connect to application # servers using the AJP protocol. This allows web applications to # be integrated seamlessly into your Apache server's URI space and # utilize Apache features such as SSL processing. # LoadModule jk2_module modules/mod_jk2.so # # Mod_jk2 is configured in /etc/httpd/conf/workers2.properties # I then created the /etc/httpd/conf/workers2.properties file. The final version that worked for me is shown below: [root@cd conf]# cat workers2.properties [logger.file:0] level=WARN file=${serverRoot}/logs/jk2.log [shm] info=Defines the shared memory file=${serverRoot}/logs/jk2.shm size=1000000 debug=0 disabled=0 [channel.socket:localhost:8009] info=Defines the local Tomcat server tomcatId=jvm1 host=localhost port=8009 [ajp13:localhost:8009] info=Defines the default ajp13 worker channel=channel.socket:localhost:8009 [status:status] info=Defines the status worker [uri:/jkstatus/*] group=status:status [uri:/scheduler/*] context=/scheduler [uri:/dspace/*] context=/dspace The only thing I had to look up for this was the tomcatId attribute, which has to have the same as the value of the jvmRoute attribute in the file /home/dspace/tomcat/conf/server.xml as shown below: [dspace@cd conf]$ grep jvm server.xml You should set jvmRoute to support load-balancing via JK/JK2 ie : Engine name="Standalone" defaultHost="localhost" debug="0" jvmRoute="jvm1" I added the dspace URI at the bottom of the workers2.properties file so that Apache would automatically refer any requests for /dspace to Tomcat. I then stopped Tomcat and added the following line to the default /home/dspace/tomcat/conf/jk2.properties file, which was otherwise just comments: channelSocket.port=8009 I started Tomcat and also restarted Apache and was delighted to find that when I visited http://cd.bromley.ac.uk/dspace it worked :-) What's more it also worked from our staff and student network behind the proxy servers :-)) With CentOS 4, mod_jk2 was not installed. I copied mod_jk2.so from Fedora Core 3 and then followed the above procedure, copying the jk2.conf and workers2.properties files as given above. I was delighted to find DSpace was then accessible via Apache. (I found the following book provided me with invaluable help in configuring Tomcat to work with Apache: Title: Tomcat 5 Author: Lapis Moczar Publisher: SAMS ISBN: 0-672-32636-1) The next task was to sort out the port address of 8080 which DSpace used when generating a self-referential URL for registration purposes. Once again this worked fine from outside college but would not work from either the staff of student networks because of the proxy problem. I edited the /home/dspace/config/dspace.cfg file and changed the following line to remove the :8080 as shown below: # DSpace base URL. Include port number etc., but NOT trailing slash dspace.url = http://cd.bromley.ac.uk/dspace I then ran the the following command to install the revised configuration: /home/dspace/bin/install-configs Next I and stopped and re-started tomcat so that the changes took effect: [dspace@cd bin]$ ./shutdown.sh Using CATALINA_BASE: /home/dspace/tomcat Using CATALINA_HOME: /home/dspace/tomcat Using CATALINA_TMPDIR: /home/dspace/tomcat/temp Using JAVA_HOME: /usr/java/jdk [dspace@cd bin]$ ./startup.sh Using CATALINA_BASE: /home/dspace/tomcat Using CATALINA_HOME: /home/dspace/tomcat Using CATALINA_TMPDIR: /home/dspace/tomcat/temp Using JAVA_HOME: /usr/java/jdk I was now able to successfully register a new user from the staff network as Dspace now provided the correct self referential URL without the 8080 included :-))) <a href="#menu">Return to Menu</a> <a name="five"></a>5) Starting DSpace Automatically With Fedora Core 3 there was already a service script to start and stop PostgreSQL. However, I needed to create two basic scripts in /etc/initd.d to start and stop tomcat and the handle server. This was to make starting DSpace easier after a power cut or kernel upgrade. As root I used an editor to create the files /etc/init.d/tomcat and /etc/init.d/handle as shown below: [root@cd ~]# cat /etc/init.d/tomcat #!/bin/sh # # description: Tomcat # # Shell script to to start/stop Tomcat # # Set Enviroment Variables and Paths # JAVA_HOME=/usr/java/jdk; export JAVA_HOME CATALINA_HOME=/home/dspace/tomcat; export CATALINA_HOME ANT_HOME=/usr/local/ant; export ANT_HOME PATH=${PATH}:${ANT_HOME}/bin PATH=${PATH}:${JAVA_HOME}/jre/bin; export PATH # case "$1" in start) # # Start Tomcat # echo sudo -u dspace /home/dspace/tomcat/bin/startup.sh ;; stop) # # Stop Tomcat # sudo -u dspace /home/dspace/tomcat/bin/shutdown.sh ;; *) echo "Usage service tomcat start/stop" exit 1;; esac [root@cd ~]# cat /etc/init.d/handle #!/bin/sh # # description: Handle Server # # Shell script to to start/stop the Handle Server for DSpace # # Set Enviroment Variables and Paths # JAVA_HOME=/usr/java/jdk; export JAVA_HOME CATALINA_HOME=/home/dspace/tomcat; export CATALINA_HOME ANT_HOME=/usr/local/ant; export ANT_HOME PATH=${PATH}:${ANT_HOME}/bin PATH=${PATH}:${JAVA_HOME}/jre/bin; export PATH # case "$1" in start) # # Start Handle Server # echo sudo -u dspace /home/dspace/bin/start-handle-server ;; stop) # # Stop Handle Server # pkill -u dspace ;; *) echo "Usage service handle start/stop" exit 1;; esac I then ran the following commands as root to make the scripts executable: [root@cd ~]# chmod 755 /etc/init.d/tomcat [root@cd ~]# chmod 755 /etc/init.d/handle Using an editor I added the following lines to the end of rc.local: service postgresql start service tomcat start service handle start DSpace now automatically starts on boot. (As root, I can also use the new commands to stop and start the tomcat and handle services manually. However, care has to be taken to get the order right and stop tomcat first, as the the handle stop script kills any remaining processes owned by user dspace.) I have also stopped the Fedora Core 3 automatic nightly yum updates to prevent an inadvertant update of PostgreSQL to version 8.0 affecting DSpace operation. I plan to review updates manually in future. <a href="#menu">Return to Menu</a> <a name="six"></a>6) Managing DSpace, Tomcat and Handle Server logs To solve the problem of managing the logs associated with DSpace, Tomcat and the Handle-Server, I created the shell script /etc/cron.weekly/dspace as shown below: [root@cd cron.weekly]# cat dspace # Custom log rotation script for DSpace # Written by Clive Gould (27th March 2005) service tomcat stop service handle stop rm -rf /home/dspace/tomcat/logs.old/* mv /home/dspace/tomcat/logs/localhost* /home/dspace/tomcat/logs.old cp /home/dspace/tomcat/logs/catalina.out /home/dspace/tomcat/logs.old cat /dev/null > /home/dspace/tomcat/logs/catalina.out # rm -rf /home/dspace/log.old/* mv /home/dspace/log/*20* /home/dspace/log.old cp /home/dspace/log/*log /home/dspace/log.old cat /dev/null > /home/dspace/log/dspace.log cat /dev/null > /home/dspace/log/handle-plugin.log cat /dev/null > /home/dspace/log/handle-server.log # rm -rf /home/dspace/handle-server/*.1 cp /home/dspace/handle-server/access.log /home/dspace/handle-server/access.log.1 cp /home/dspace/handle-server/error.log /home/dspace/handle-server/error.log.1 cat /dev/null > /home/dspace/handle-server/access.log cat /dev/null > /home/dspace/handle-server/error.log # service tomcat start service handle start I made it executable using the following command: [root@cd cron.weekly]# chmod 755 dspace I then became user dspace and created the two .old log directories as shown below: [root@cd cron.weekly]# su - dspace [dspace@cd ~]$ mkdir log.old [dspace@cd ~]$ mkdir tomcat/logs.old <a href="#menu">Return to Menu</a> <a name="seven"></a>7) Making DSpace available via Apache and HTTPS The default install of Apache with Fedora Core 3 provides full HTTPS access on port 443. On visiting https://cd.bromley.ac.uk/dspace I found that DSpace came up over a secure connection without any further work on my part :-) (My understanding is that the browser communicates with Apache over a secure https connection via port 443 and then Apache communicates with Tomcat via the existing internal connection. This means that Tomcat does not need to be re-configured to listen over a secure connection.) In order for DSpace to reference the revised URL correctly I edited the /home/dspace/config/dspace.cfg file as user dspace and changed the following line to add the https service as shown below: # DSpace base URL. Include port number etc., but NOT trailing slash dspace.url = https://cd.bromley.ac.uk/dspace I then ran the the following command to install the revised configuration: /home/dspace/bin/install-configs Next, as user root, I and stopped and re-started both tomcat and the handle server so that the changes took effect: service tomcat stop service handle stop service tomcat start service handle start DSpace now worked fully with https, with all paths correct and handles resolving to the new URL. The next step was to create a valid certificate as Apache was currently using just the localhost.localdomain certificate that came with the default install of Fedora. I found the following website provided invaluable guidance on creating a certificate: <a href="http://www.tc.umn.edu/~brams006/selfsign.html">http://www.tc.umn.edu/~brams006/selfsign.html</a> The commands I used, as root (with the system responses shown in italic and my responses shown in bold where apppriate), are illustrated below: cd mkdir certwork chmod 750 certwork cd certwork I generated the Certificate Authority myself as shown below: [root@cd certwork]# openssl genrsa -des3 -out ca.key 4096 Generating RSA private key, 4096 bit long modulus ..............................................................................................................................................................................++ .........................++ e is 65537 (0x10001) Enter pass phrase for ca.key: Verifying - Enter pass phrase for ca.key: [root@cd certwork]# openssl req -new -x509 -days 365 -key ca.key -out ca.crt Enter pass phrase for ca.key: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [GB]:GB State or Province Name (full name) [Berkshire]:Kent Locality Name (eg, city) [Newbury]:Bromley Organization Name (eg, company) [My Company Ltd]:Bromley College Organizational Unit Name (eg, section) []:School of ICT Common Name (eg, your name or your server's hostname) []:cd.bromley.ac.uk Email Address []:root@cd.bromley.ac.uk I then generated a server key and request for signing as shown below: [root@cd certwork]# openssl genrsa -des3 -out server.key 4096 Generating RSA private key, 4096 bit long modulus ..........++ .....................................................++ e is 65537 (0x10001) Enter pass phrase for server.key: Verifying - Enter pass phrase for server.key: [root@cd certwork]# openssl req -new -key server.key -out server.csr Enter pass phrase for server.key: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [GB]:GB State or Province Name (full name) [Berkshire]:Kent Locality Name (eg, city) [Newbury]:Bromley Organization Name (eg, company) [My Company Ltd]:Bromley College Organizational Unit Name (eg, section) []:School of ICT Common Name (eg, your name or your server's hostname) []:cd.bromley.ac.uk Email Address []:root@cd.bromley.ac.uk Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: I then signed the certificate signing request with the self-created certificate authority that I made earlier: [root@cd certwork]# openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -signkey server.key -set_serial 01 -out server.crt Signature ok subject=/C=GB/ST=Kent/L=Bromley/O=Bromley College/OU=School of ICT/CN=cd.bromley.ac.uk/emailAddress=root@cd.bromley.ac.uk Getting CA Private Key Enter pass phrase for ca.key: Getting Private key Enter pass phrase for server.key: I then created an "insecure" server key to prevent Apache asking for a password every time I tried to restart the httpd process: [root@cd certwork]# openssl rsa -in server.key -out server.key.insecure Enter pass phrase for server.key: writing RSA key [root@cd certwork]# mv server.key server.key.secure [root@cd certwork]# mv server.key.insecure server.key As root, I then copied the keys over to the appropriate Apache directories as shown below: cp /root/certwork/server.key /etc/httpd/conf/ssl.key cp /root/certwork/server.crt /etc/httpd/conf/ssl.crt cp /root/certwork/server.csr /etc/httpd/conf/ssl.csr To be on the safe side I also changed the permissions of the above files to 600 as shown below: chmod 600 /etc/httpd/conf/ssl.key/server.key chmod 600 /etc/httpd/conf/ssl.crt/server.crt chmod 600 /etc/httpd/conf/ssl.csr/server.csr As root, I then restarted Apache: [root@cd certwork]# service httpd restart Stopping httpd: [ OK ] Starting httpd: [ OK ] When I visited DSpace from a browser the new certificate was successfully presented for acceptance :-) <a href="#menu">Return to Menu</a> <a name="eight"></a>8) Changing the contact telephone number When a contact message is displayed the phone number comes up with the default of xxx-555-xxxx To change this I edited the file /home/dspace/dspace-1.2.1-source/jsp/components/contact-info.jsp and changed the text shown in bold: td class="standard" Or telephone: /td td class="standard" 020 8295 7000 x7144 /td (Please note that in the lines above the opening and closing html tags have been removed as otherwise the blog does not display properly.) I then rebuilt DSpace as shown below: [dspace@cd dspace-1.2.1-source]$ ant -Dconfig=/home/dspace/config/dspace.cfg build_wars Buildfile: build.xml compile: build_wars: [copy] Copying 1 file to /home/dspace/dspace-1.2.1-source/build/jsp [war] Building war: /home/dspace/dspace-1.2.1-source/build/dspace.war BUILD SUCCESSFUL Total time: 3 seconds I then stopped Tomcat as root: [dspace@cd dspace-1.2.1-source]$ su - root Password: [root@cd ~]# service tomcat stop Using CATALINA_BASE: /home/dspace/tomcat Using CATALINA_HOME: /home/dspace/tomcat Using CATALINA_TMPDIR: /home/dspace/tomcat/temp Using JAVA_HOME: /usr/java/jdk [root@cd ~]# I then exited back to user DSpace and removed the tomcat dspace directory: [dspace@cd dspace]$ rm -rf /home/dspace/tomcat/webapps/dspace I then copied over the dspace.war file into the webapps directory: [dspace@cd dspace]$ cp /home/dspace/dspace-1.2.1-source/build/dspace.war /home/dspace/tomcat/webapps I then restarted Tomcat as root: [dspace@cd webapps]$ su - root Password: [root@cd ~]# service tomcat start Using CATALINA_BASE: /home/dspace/tomcat Using CATALINA_HOME: /home/dspace/tomcat Using CATALINA_TMPDIR: /home/dspace/tomcat/temp Using JAVA_HOME: /usr/java/jdk Hurray - contact details are now as shown below: DSpace at Bromley College administration contact details: By e-mail: dspace-help@cd.bromley.ac.uk Or telephone: 020 8295 7000 x7144 <a href="#menu">Return to Menu</a> <a name="nine"></a>9) Upgrading to Tomcat 5.5 I decided to upgrade Tomcat to the latest version. (I had read that Tomcat 5.5 needed the JRE, but on further investigation found that the JRE was already included in a download of the JDK.) Before installing Tomcat 5.5 I downloaded and installed the latest JDK from Sun, as root, using the commands shown below: cd /usr/java lynx http://java.sun.com/j2se/1.5.0/download.jsp chmod 755 *.bin ./jdk-1_5_0_02-linux-i586.bin rm *.bin cp -pr jdk1.5.0_02 jdk As user dspace, I downloaded the latest version of Tomcat and unpacked it into the dspace home directory using the commands shown below: cd /home/dspace lynx http://jakarta.apache.org/site/downloads/downloads_tomcat-5.cgi tar -xzvf jakarta-tomcat-5.5.7.tar.gz As user root, I stopped Apache using the command: service httpd stop As user dspace, I then completed the installation using the commands shown below: service tomcat stop service handle stop mv tomcat tomcat-4.1 mv jakarta-tomcat-5.5.7 tomcat cd /home/dspace/dspace-1.2.1-source/build/ cp *.war /home/dspace/tomcat/webapps service tomcat start service handle start As user root, I started Apache using the command: service httpd start Amazingly DSpace worked perfectly with Tomcat 5.5 first time and with no problems :-) <a href="#menu">Return to Menu</a> <a name="ten"></a>10) DSpace 1.2.2 upgrade procedure 7th May 2005: Downloaded DSpace 1.2.2 from the Dublin mirror into the /home/dspace directory as follows: [dspace@cd ~]$ lynx http://prdownloads.sourceforge.net/dspace/dspace-1.2.2-source.tar.gz?download Unpacked the file within the /home/dpsace directory: [dspace@cd ~]$ tar -xzvf dspace-1.2.2-source.tar.gz removed the download file: [dspace@cd ~]$ rm dspace-1.2.2-source.tar.gz Needed to find the update documentation so used the following commands to copy over the update.html into the Apache webserver root directory from where I could read it using a browser: cd dspace-1.2.2-source/docs su root cp update.html /var/www/html exit From now on this upgrade follows the procedure given in the upgrade.html document. Copied over the jar file as follows: [dspace@cd ~]$ cd dspace-1.2.1-source/lib [dspace@cd lib]$ cp pg74.215.jdbc3.jar ../../dspace-1.2.2-source/lib Stopped Tomcat and the handle-server as follows: [dspace@cd lib]$ su - root Password: [root@cd ~]# service tomcat stop Using CATALINA_BASE: /home/dspace/tomcat Using CATALINA_HOME: /home/dspace/tomcat Using CATALINA_TMPDIR: /home/dspace/tomcat/temp Using JRE_HOME: /usr/java/jdk [root@cd ~]# service handle stop [root@cd ~]# exit Added the following lines to the end of /home/dspace/config/dspace.cfg ##### Fulltext Indexing settings ##### # Maximum number of terms indexed for a single field in Lucene. # Default is 10,000 words - often not enough for full-text indexing. # If you change this, you'll need to re-index for the change # to take effect on previously added items. # -1 = unlimited (Integer.MAX_VALUE) search.maxfieldlength = 10000 Changed to the directory dspace-1.2.2-source and ran the ant update command: [dspace@cd ~]$ cd dspace-1.2.2-source [dspace@cd dspace-1.2.2-source]$ ant -Dconfig=/home/dspace/config/dspace.cfg update Buildfile: build.xml compile: [mkdir] Created dir: /home/dspace/dspace-1.2.2-source/build/classes [javac] Compiling 136 source files to /home/dspace/dspace-1.2.2-source/build/classes [javac] /home/dspace/dspace-1.2.2-source/src/org/dspace/browse/Browse.java:367: warning: non-varargs call of varargs method with inexact argument type for last parameter; [javac] cast to java.lang.Object for a varargs call [javac] cast to java.lang.Object[] for a non-varargs call and to suppress this warning [javac] new String[] { browseTables[i] }); [javac] ^ [javac] Note: * uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 1 warning install_code: [copy] Copying 5 files to /home/dspace/lib [jar] Building jar: /home/dspace/lib/dspace.jar build_wars: [copy] Copying 1 file to /home/dspace/dspace-1.2.2-source/build [mkdir] Created dir: /home/dspace/dspace-1.2.2-source/jsp/local [mkdir] Created dir: /home/dspace/dspace-1.2.2-source/build/jsp [copy] Copying 194 files to /home/dspace/dspace-1.2.2-source/build/jsp [war] Building war: /home/dspace/dspace-1.2.2-source/build/dspace.war [copy] Copying 1 file to /home/dspace/dspace-1.2.2-source/build [war] Building war: /home/dspace/dspace-1.2.2-source/build/dspace-oai.war update: [echo] [echo] ==================================================================== [echo] Updated Web application (.war) files are in the 'build' directory. [echo] [echo] * Stop your Web servlet container (Tomcat, Jetty, Resin etc.) [echo] [echo] * If you're using Tomcat, you need delete the directories [echo] corresponding to the old .war files. For example, if dspace.war [echo] is installed in CATALINA_HOME/webapps/dspace.war, you should [echo] delete the CATALINA_HOME/webapps/dspace directory. Otherwise, [echo] Tomcat will continue to use the old code in that directory. [echo] [echo] * Copy the new dspace.war and dspace-oai.war from the 'build' [echo] directory over the old ones [echo] [echo] * Start up your Web servlet container again. [echo] ==================================================================== [echo] BUILD SUCCESSFUL Total time: 10 seconds Removed all the old files and directories associated with DSpace form the tomcat/webapps directory: [dspace@cd ~]$ cd tomcat/webapps [dspace@cd webapps]$ rm -rf dspace* Copied over the new .war files into the tomcat/webapps directory: [dspace@cd ~]$ cd dspace-1.2.2-source/build [dspace@cd build]$ cp dspace*.war /home/dspace/tomcat/webapps Copied over the input-forms.xml file and then restarted Tomcat and the handle-server: [dspace@cd ~]$ cd dspace-1.2.2-source/config [dspace@cd config]$ cp input-forms.xml /home/dspace/config [dspace@cd config]$ su - root Password: [root@cd ~]# service tomcat start Using CATALINA_BASE: /home/dspace/tomcat Using CATALINA_HOME: /home/dspace/tomcat Using CATALINA_TMPDIR: /home/dspace/tomcat/temp Using JRE_HOME: /usr/java/jdk [root@cd ~]# service handle start [root@cd ~]# exit Hurray DSpace still works :-))) Correcting the telephone number (again) 19th May 2005 - The only problem I have encountered with the upgrade is that the contact phone number has been reset to the default value. To correct this I followed a slightly modified version of the procedure given above for changing the phone number in DSpace 1.2.1 The procedure I followed was: Logged on as user dspace and edited the contact info configuration file: [dspace@cd ~]$ nano dspace-1.2.2-source/jsp/components/contact-info.jsp and changed the text shown in bold: td class="standard" Or telephone: /td td class="standard" 020 8295 7000 x7144 /td (Please note that in the lines above the opening and closing html tags have been removed as otherwise the blog does not display properly.) I then rebuilt DSpace as shown below: [dspace@cd components]$ cd /home/dspace/dspace-1.2.2-source [dspace@cd dspace-1.2.2-source]$ ant -Dconfig=/home/dspace/config/dspace.cfg build_wars Buildfile: build.xml compile: build_wars: [copy] Copying 1 file to /home/dspace/dspace-1.2.2-source/build/jsp [war] Building war: /home/dspace/dspace-1.2.2-source/build/dspace.war BUILD SUCCESSFUL Total time: 4 seconds I then stopped Tomcat as root: [dspace@cd dspace-1.2.2-source]$ su - root Password: [root@cd ~]# service tomcat stop Using CATALINA_BASE: /home/dspace/tomcat Using CATALINA_HOME: /home/dspace/tomcat Using CATALINA_TMPDIR: /home/dspace/tomcat/temp Using JRE_HOME: /usr/java/jdk I then exited back to user DSpace and removed the tomcat dspace directory: [root@cd ~]# exit logout [dspace@cd dspace-1.2.2-source]$ rm -rf /home/dspace/tomcat/webapps/dspace I then copied over the dspace.war file into the webapps directory: [dspace@cd dspace-1.2.2-source]$ cp /home/dspace/dspace-1.2.2-source/build/dspace.war /home/dspace/tomcat/webapps I then restarted Tomcat as root: [dspace@cd dspace-1.2.2-source]$ su - root Password: [root@cd ~]# service tomcat start Using CATALINA_BASE: /home/dspace/tomcat Using CATALINA_HOME: /home/dspace/tomcat Using CATALINA_TMPDIR: /home/dspace/tomcat/temp Using JRE_HOME: /usr/java/jdk [root@cd ~]# exit logout The modified telephone number now displayed correctly. <a href="#menu">Return to Menu</a> <a name="eleven"></a>11) Customising the Web User Interface Now that DSpace has been installed on one of our new mission critical servers I wanted to extensively customise the web interface so that it matched the theme already employed on the College Website and Moodle VLE. I found the customisation <a href="http://dspace.org/technology/system-docs/configure.html#customui">information</a> on the DSpace Website a useful starting point. I logged on as user DSpace and moved to the jsp directory: cd dspace-1.2.2-source/jsp I then created two subdirectories of local as follows: mkdir local/image mkdir local/layout I then copied the following files as shown below: cp image/arrow.gif local/image cp image/search-go.gif local/image cp styles.css.jsp local cp layout/header-default.jsp local/layout I then spent a long time customising the files local/styles.css.jsp and local/layout/header-default.jsp - the only real way I found of doing this was trial and error until eventually I got the desired effect This proved very time consuming as after each change I had to su to root and stop tomcat before returning to user DSpace and recompiling DSpace as shown below: ant -Dconfig=[dspace]/config/dspace.cfg build_wars rm -rf /home/dspace/tomcat/webapps/dspace cp /home/dspace/dspace-1.2.2-source/build/dspace.war /home/dspace/tomcat/webapps I then had to su to root again to restart tomcat before I could preview my changes in the browser. I also had to alter the graphics files in local/image to suit the new theme, which involved using The GIMP at one point. You can see my completed themed interface by visting <a href="http://vle.bromley.ac.uk/dspace">http://vle.bromley.ac.uk/dspace</a> I addition to customising the interface I also customised (customized) the default DSpace licence (license) agreement so that it related to Bromley College and not DSpace University (DSU). This was a two stage procedure. Firstly, I edited the default license file at /home/dspace/dspace-1.2.2-source/config/default.license and then recompiled DSpace. (However, this did not change the license agreements associated with pre-existing collections.) Secondly, in order to change the licence agreements associated with pre-existing collections I had to log onto DSpace as administrator and change the license agreement associated with each collection individually. I found that I had to insert a br tag at the beginning of every other line within the dialog box in order to make the layout of the completed agreement acceptable. <a href="#menu">Return to Menu</a> <a name="twelve"></a>12) Virus scanning and establishing a hot backup server With the DSpace Repository and Moodle VLE becoming mission critical this summer we needed to have a backup server that could be brought online at a moments notice in case the there were problems with the main server. We bought in two identical rack mount servers from Dell each with twin 3.2GHz Xeon processors, 3 x 73GB hard drives in a RAID 5 hardware array and 4GB of RAM. I installed CentOS 4 on both servers with no problems at all during the actual installation. The two servers are to be placed in different server room locations in the College and will have Internet/Intranet access via a hardware NAT firewall. I have decided that either server can be booted into one of three modes: 1) Main - provides Web Services 2) Backup - provides Backup services for the main server 3) Standby - an intermediate mode Each mode has its own external IP address and domain name. When a server is in Main mode a cron.daily script runs a backup script from the root users bin folder. This script scans the DSpace and Moodle asset store folders for Windows viruses and uses rsync to synchronise the build on the Main server with the build on the Backup server. Additionally it also uses rsync to separately backup the DSpace and Moodle builds and databases on Sunday morning and the 28th of each month. This script is illustrated below: [root@cc bin]# cat backup /usr/local/bin/freshclam --quiet echo "Moodle anti-virus scan" /usr/local/bin/clamscan --infected --move=/home/infected -r /home/bcvle echo " " 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 "/sys/" --exclude "/media/" --exclude "/proc/" --exclude "/dev/pts/" --exclude "/var/run/" --exclude "/var/log/" --exclude "/etc/cups/" --exclude "/var/lock/" --exclude "/etc/hosts" --exclude "/etc/sysconfig/network" --exclude "/etc/sysconfig/network-scripts/" --exclude "/var/lib/mrtg/mrtg.ok" --exclude "/var/lib/slocate/" --exclude "/var/lib/slocate/slocate.db" --exclude "/var/lib/ntp/" --exclude "/root/.bashrc" --exclude "/home/clive/.bashrc" --exclude "/etc/cron.weekly/dspace" --exclude "/home/backup/" --exclude "/etc/mail/sendmail.cf" --exclude "/var/spool/mail/" --exclude "/var/spool/mqueue/" --exclude "/var/spool/clientmqueue/" --exclude "/root/bin/backup" --exclude "/etc/rc.d/rc.local" --exclude "/var/spool/cron/dspace" --exclude "/etc/rsyncd.conf" / 172.31.0.6::backup rsync /var/log/freshclam.log 172.31.0.6::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/bcvle /home/backup/weekly rsync -av --delete /home/bcvleuser /home/backup/weekly rsync -av --delete /var/lib/mysql/bcvle /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/bcvle /home/backup/monthly rsync -av --delete /home/bcvleuser /home/backup/monthly rsync -av --delete /var/lib/mysql/bcvle /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 following scripts are used to switch the server between the modes: [root@cc bin]# cat 0mkmain # "This script puts a server into MAIN mode" cp -f /root/bin/0Mainfiles/dspace /etc/cron.weekly cp -f /root/bin/0Mainfiles/hosts /etc/hosts cp -f /root/bin/0Mainfiles/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0 cp -f /root/bin/0Mainfiles/rc.local /etc/rc.d/rc.local cp -f /root/bin/0Mainfiles/network /etc/sysconfig/network cp -f /root/bin/0Mainfiles/backup /root/bin/backup cp -f /root/bin/0Mainfiles/sendmail.cf /etc/mail cp -f /root/bin/0Mainfiles/dspacecron /var/spool/cron/dspace rm -rf /etc/rsyncd.conf &> /dev/null echo "[ctrl]+[c] will cancel a running shutdown" shutdown -r +1 [root@cc bin]# cat 0mkback # This script puts the server into BACKUP mode" echo "If this is the main server do you need to run the backup script first?" cp -f /root/bin/0Backupfiles/rsyncd.conf /etc/rsyncd.conf cp -f /root/bin/0Backupfiles/hosts /etc/hosts cp -f /root/bin/0Backupfiles/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0 cp -f /root/bin/0Backupfiles/rc.local /etc/rc.d/rc.local cp -f /root/bin/0Backupfiles/network /etc/sysconfig/network cp -f /root/bin/0Backupfiles/backup /root/bin/backup cp -f /root/bin/0Backupfiles/sendmail.cf /etc/mail rm -rf /etc/cron.weekly/dspace &> /dev/null crontab -u dspace -r echo "[ctrl]+[c] will cancel a running shutdown" shutdown -r +1 [root@cc bin]# cat 0mkstnd # "This script puts a server into STANDBY mode" cp -f /root/bin/0Standbyfiles/hosts /etc/hosts cp -f /root/bin/0Standbyfiles/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0 cp -f /root/bin/0Standbyfiles/rc.local /etc/rc.d/rc.local cp -f /root/bin/0Standbyfiles/network /etc/sysconfig/network cp -f /root/bin/0Standbyfiles/backup /root/bin/backup cp -f /root/bin/0Standbyfiles/sendmail.cf /etc/mail rm -rf /etc/cron.weekly/dspace &> /dev/null crontab -u dspace -r echo "[ctrl]+[c] will cancel a running shutdown" shutdown -r +1 By logging into both servers using ssh it is possible to switch modes quickly and easily using the above scripts. <a href="#menu">Return to Menu</a> <a name="thirteen"></a>1) Upgrading to DSpace 1.3.1 These upgrade instructions are specifically written for CentOS 4. I am using Fedora Core 3 on several other servers, but am not running DSpace on these servers any more. I initially upgraded to Dspace 1.3 only to find that 1.3.1 came out the next morning! These upgrade instructions are written for the upgrade from 1.2.2 to 1.3.1. These instructions follow on from earlier items in this blog and assume that DSpace 1.2.2 is already installed in /home/dspace. Back up up all your data before proceeding. Include all of the contents of /home/dspace and the /var/lib/pgsql/data in your backup. Have a look at the rsync commands in the backup script in the previous section in this blog if you need help with backup. Login as the dspace user and download dspace-1.3.1-source.tar.gz into /home/dspace using the command: lynx http://sourceforge.net/project/showfiles.php?group_id=19984 Unpack the new installation using the following command: cd /home/dspace tar -xzvf dspace-1.3.1-source.tar.gz rm *.gz I needed to find the update documentation so I used the following commands to copy over the docs folder into the Apache webserver root directory from where I could read it using a browser: cd dspace-1.3.1-source su root cp -pr docs /var/www/html exit From now on this upgrade follows the procedure given in the upgrade.html document. Copy the PostgreSQL driver JAR from the 1.2.2 source directory to the 1.3.1 source directory: cp /home/dspace/dspace-1.2.2-source/lib/pg74.215.jdbc3.jar /home/dspace/dspace-1.3.1-source/lib (Note that there was a problem with the upgrade documentation that I downloaded in that it included the following command, which is an error: cp postgresql.jar [dspace-1.2.2-source]/lib) Remove the old version of xerces.jar from your installation, so it is not inadvertently later used: rm /home/dspace/lib/xerces.jar Take down Tomcat and the handle-server: su - root service tomcat stop service handle stop exit Install the new config files by moving dstat.cfg and dstat.map: cp /home/dspace/dspace-1.3.1-source/config/dstat* /home/dspace/config You need to append the following new parameters to /home/dspace/config/dspace.cfg: ###### Statistical Report Configuration Settings ###### # should the stats be publicly available? should be set to false if you only # want administrators to access the stats, or you do not intend to generate # any report.public = false # directory where live reports are stored report.dir = /home/dspace/reports/ I suggest you leave customising the statistics feature until after the upgrade is complete. The instructions in section 14 of this blog explain how to get statistics working. If the Web interface has been customised, copy over any custom interface files: cp /home/dspace/dspace-1.2.2-source/jsp/components/contact-info.jsp /home/dspace/dspace-1.3.1-source/jsp/components/contact-info.jsp cp -pr /home/dspace/dspace-1.2.2-source/jsp/local /home/dspace/dspace-1.3.1-source/jsp (Note: If the interface hasn't been customised you can miss out the above step) Build and install the updated DSpace 1.3.1 code. Go to the /home/dspace/dspace-1.3.1-source directory, and run: ant -Dconfig=/home/dspace/config/dspace.cfg update Buildfile: build.xml compile: install_code: [copy] Copying 1 file to /home/dspace/lib [jar] Building jar: /home/dspace/lib/dspace.jar build_wars: [copy] Copying 2 files to /home/dspace/dspace-1.3.1-source/build/jsp [copy] Copying 6 files to /home/dspace/dspace-1.3.1-source/build/jsp [war] Building war: /home/dspace/dspace-1.3.1-source/build/dspace.war [war] Building war: /home/dspace/dspace-1.3.1-source/build/dspace-oai.war update: [echo] [echo] ==================================================================== [echo] Updated Web application (.war) files are in the 'build' directory. [echo] [echo] * Stop your Web servlet container (Tomcat, Jetty, Resin etc.) [echo] [echo] * If you're using Tomcat, you need delete the directories [echo] corresponding to the old .war files. For example, if dspace.war [echo] is installed in CATALINA_HOME/webapps/dspace.war, you should [echo] delete the CATALINA_HOME/webapps/dspace directory. Otherwise, [echo] Tomcat will continue to use the old code in that directory. [echo] [echo] * Copy the new dspace.war and dspace-oai.war from the 'build' [echo] directory over the old ones [echo] [echo] * Start up your Web servlet container again. [echo] ==================================================================== [echo] BUILD SUCCESSFUL Total time: 6 seconds In order to modify the existing PostgreSQL database structure to meet the requirements of DSpace 1.3.1 is necessary to run the database_schema_12-13.sql file. To apply the changes, go to the 1.3.1 source directory, and run: [dspace@cc dspace-1.3.1-source]$ cd etc [dspace@cc etc]$ psql -f database_schema_12-13.sql dspace -h localhost Password: CREATE SEQUENCE psql:database_schema_12-13.sql:60: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "epersongroup2item_pkey" for table "epersongroup2workspaceitem" CREATE TABLE ALTER TABLE ALTER TABLE psql:database_schema_12-13.sql:70: NOTICE: ALTER TABLE / ADD UNIQUE will create implicit index "eperson_netid_key" for table "eperson" ALTER TABLE CREATE INDEX CREATE INDEX CREATE INDEX CREATE INDEX CREATE INDEX CREATE INDEX CREATE INDEX CREATE INDEX CREATE INDEX Rebuild the search indices: ./index-all Creating browse index Indexing all Items in DSpace.... ... Done Creating search index Done with indexing Remove any old dspace Tomcat files: rm -rf /home/dspace/tomcat/webapps/*dspace* Copy over new .war files: cp /home/dspace/dspace-1.3.1-source/build/*.war /home/dspace/tomcat/webapps Restart tomcat and the handle server su - root service tomcat start Using CATALINA_BASE: /home/dspace/tomcat Using CATALINA_HOME: /home/dspace/tomcat Using CATALINA_TMPDIR: /home/dspace/tomcat/temp Using JRE_HOME: /usr/java/jdk service handle start exit Hurray DSpace 1.3.1 works :-))) Subsequently I noticed that some images associated with the item submission process could no longer be found. I located these in last month's backup of DSpace 1.2.2 and copied them over into the /home/dspace/dspace-1.3.1-source/jsp/images/submit directory and rebuilt DSpace. The images now appear correctly during the submission process. <a href="#menu">Return to Menu</a> <a name="fourteen"></a>14) Getting statistics working I order to get statistics working I edited the /home/dspace/config/dstat.cfg file and made the following changes to the file: # the log directory to be analysed dspace.log=/home/dspace/log # The item types in the archive that you need number breakdowns on item.type=Animation item.type=Article item.type=Book item.type=Book chapter item.type=Dataset item.type=Learning Object item.type=Image item.type=Image, 3D item.type=Map item.type=Musical Score item.type=Plan or Blueprint item.type=Preprint item.type=Presentation item.type=Recording, acoustical item.type=Recording, musical item.type=Recording, oral item.type=Software item.type=Technical Report item.type=Thesis item.type=Video item.type=Working Paper item.type=Other # the name and url of the service being reported on host.name=DSpace at Bromley College host.url=http://vle.bromley.ac.uk/dspace I then moved to the directory /home/dspace/bin and edited each of the following scripts in turn, changing the default path for the dspace home directory from /dspace to /home/dspace where appropriate: stat-initial stat-report-initial stat-monthly stat-report-monthly stat-general stat-report-general In order to initialise the statistics feature, I then ran each of the above scripts in turn from the command line, as user dspace. The function of each script (thanks to Richard Jones for help in understanding these) is given below: stat-initial: analyses the dspace logs (the analyser will perform its actions on any file which conforms to the regular expression: "dspace\.log.*") and generates monthly data files for all the complete months from the beginning of January to the end of the previous month. The data files (.dat) are placed in the log directory. stat-report-initial: generates an HTML output from each of above monthly data files and places the HTML files in the reports directory. stat-monthly: analyses the dspace logs and generates a data file for the current month. stat-report-monthly: generates an HTML output from the current months' data file. stat-general: analyses the dspace logs and generates a data file from the start to the end of the logs. stat-report-general: generates an HTML output from above data file. This script generates the default statistics home page, headed "Most recent general report". At this point I revisited https://vle.bromley.ac.uk/dspace/statistics and found the statistics were now available :-))) I then added the following lines to the dspace crontab: # Run the dspace analysis scripts 30 2 * * * /home/dspace/bin/stat-monthly 0 3 * * * /home/dspace/bin/stat-general # Run the dspace reporting scripts 30 3 * * * /home/dspace/bin/stat-report-monthly 0 4 * * * /home/dspace/bin/stat-report-general With the above settings the current months' report and the most recent general report is updated every night. I noticed that the only period with relevant Web statistics available was the current week. I presumed that this was because I had set up a shell script /etc/cron.weekly/dspace to rotate the dspace logs every Sunday morning. In order to retain more useful log information for statistics purposes I have commented out the following lines in the above file: # mv /home/dspace/log/*20* /home/dspace/log.old # cp /home/dspace/log/*log /home/dspace/log.old # cat /dev/null > /home/dspace/log/dspace.log <a href="#menu">Return to Menu</a> <a name="fifteen"></a>15) Modified handle server configuration I am in the process of changing the hostname of the server running Moodle and DSpace and have noted that the handle-server configuration has changed recently. The modified handle server configuration that I used with DSpace 1.3.1 is illustrated below: dsrun net.handle.server.SimpleSetup /home/dspace/handle-server To configure your new Handle or Caching server, please answer the questions which follow; default answers, shown in [square brackets] when available, can be chosen by pressing Enter. Will this be a caching server or a regular handle server? 1 - regular Handle Server (Recommended) 2 - caching Handle Server Please choose 1 or 2 and press Enter [1]: Will this be a "primary" server (ie, not a mirror of another server)?(y/n) [y]: Through what IP address will this server be accessible? (Domain names are OK) [10.200.0.14]: Enter the (TCP/UDP) port number this server will listen to [2641]: What port number will the HTTP interface be listening to? [8000]: Would you like to log all accesses to this server?(y/n) [n]: y Please indicate whether log files should be automatically rotated, and if so, how often. ("N" (Never), "M" (Monthly), "W" (Weekly), or "D" (Daily))? [Never] : M NOTE: Auto-saves and restarts will be done on the first of each month. Select a time of day for the saving and restarting (HH:MM:SS) [00:00:00]: Enter the full pathname of the directory where saved logs should be stored [/home/dspace/handle-server]: Each handle site has a version/serial number assigned to it. This is so that a client can tell if a particular site's configuration has changed since the last time it accessed a server in the site. Every time you modify a site (by changing an IP address, port, or adding a server, etc), you should increment the version/serial number for that site. Enter the version/serial number of this site [1]: Please enter a short description of this server/site: Bromley College DSpace Repository Please enter the name of your organization: Bromley College Please enter the name of a contact person for Bromley College (optional) [(none)]: Clive Gould Please enter the telephone number of Clive Gould or of Bromley College (optional) [(none)]: 020 8295 7000 Please enter the email address of Clive Gould or of Bromley College: xyz@.bromley.ac.uk The Handle System can communicate via UDP and/or TCP sockets. Since UDP messages are blocked by many network firewalls, you may want to disable UDP services if you are behind such a firewall. Would you like to disable UDP services?(y/n) [n]: y Server keys already exist, do you want to create new ones? (y/n) [n]: Administrator keys already exist, do you want to create new ones? (y/n) [n]: Generating site info record... ------------------------------------------------------- Finished configuring regular (primary) Handle Server. In order for the outside world to find your site, you will need to have a naming authority and a reference to your site in the root handle service. To request a naming authority, please visit http://hdl.handle.net/4263537/5014 I visited the above web page and filled in the form, including both our internal and external IP addresses and attaching sitebndl.zip and within a very short time I got an email from CNRI to say that our existing handle prefix had been updated in their database. Handles would not resolve properly as the new server was behind a hardware firewall. We opened firewall ports 2641 and 8000 to incoming and outgoing traffic and all was well. <a href="#menu">Return to Menu</a> <a name="sixteen"></a>16) Upgrading to DSpace 1.3.2 These upgrade instructions are specifically written for CentOS 4. I am using Fedora Core 3 on several other servers, but am not running DSpace on these servers any more. These instructions follow on from earlier items in this blog and assume that DSpace 1.3.1 is already installed in /home/dspace. Back up up all your data before proceeding. Include all of the contents of /home/dspace and the /var/lib/pgsql/data in your backup. Have a look at the rsync commands in the backup script in the previous section in this blog if you need help with backup. Login as the dspace user and download dspace-1.3.2-source.tar.gz into /home/dspace using the command: lynx http://heanet.dl.sourceforge.net/sourceforge/dspace/dspace-1.3.2-source.tar.gz Unpack the new installation using the following command: cd /home/dspace tar -xzvf dspace-1.3.2-source.tar.gz rm *.gz Copy the PostgreSQL driver JAR from the 1.3.1. source directory to the 1.3.2 source directory: cp /home/dspace/dspace-1.3.1-source/lib/pg74.215.jdbc3.jar /home/dspace/dspace-1.3.2-source/lib Take down Tomcat and the handle-server: su - root service tomcat stop service handle stop exit Make a backup copy of the new 1.3.2 dspace.cfg file and just copy over the old version of dspace.cfg unless you are using either SRB File Storage or LDAP Authentication: cp /home/dspace/dspace-1.3.2-source/config/dspace.cfg /home/dspace/dspace-1.3.2-source/config/dspace.cfg.default cp /home/dspace/dspace-1.3.1-source/config/dspace.cfg /home/dspace/dspace-1.3.2-source/config If the Web interface has been customised, copy over any custom interface files. For example: cp /home/dspace/dspace-1.3.1-source/jsp/components/contact-info.jsp /home/dspace/dspace-1.3.2-source/jsp/components/contact-info.jsp cp -pr /home/dspace/dspace-1.3.1-source/jsp/local /home/dspace/dspace-1.3.2-source/jsp Build and install the updated DSpace 1.3.2 code. Go to the /home/dspace/dspace-1.3.2-source directory, and run: ant -Dconfig=/home/dspace/config/dspace.cfg update Buildfile: build.xml compile: [mkdir] Created dir: /home/dspace/dspace-1.3.2-source/build/classes [javac] Compiling 151 source files to /home/dspace/dspace-1.3.2-source/build/classes [javac] Note: * uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. install_code: [copy] Copying 1 file to /home/dspace/lib [jar] Building jar: /home/dspace/lib/dspace.jar build_wars: [copy] Copying 1 file to /home/dspace/dspace-1.3.2-source/build [mkdir] Created dir: /home/dspace/dspace-1.3.2-source/build/jsp [copy] Copying 194 files to /home/dspace/dspace-1.3.2-source/build/jsp [copy] Copying 6 files to /home/dspace/dspace-1.3.2-source/build/jsp [copy] Copying 1 file to /home/dspace/dspace-1.3.2-source/build/classes [war] Building war: /home/dspace/dspace-1.3.2-source/build/dspace.war [copy] Copying 1 file to /home/dspace/dspace-1.3.2-source/build [war] Building war: /home/dspace/dspace-1.3.2-source/build/dspace-oai.war update: [echo] [echo] ==================================================================== [echo] Updated Web application (.war) files are in the 'build' directory. [echo] [echo] * Stop your Web servlet container (Tomcat, Jetty, Resin etc.) [echo] [echo] * If you're using Tomcat, you need delete the directories [echo] corresponding to the old .war files. For example, if dspace.war [echo] is installed in CATALINA_HOME/webapps/dspace.war, you should [echo] delete the CATALINA_HOME/webapps/dspace directory. Otherwise, [echo] Tomcat will continue to use the old code in that directory. [echo] [echo] * Copy the new dspace.war and dspace-oai.war from the 'build' [echo] directory over the old ones [echo] [echo] * Start up your Web servlet container again. [echo] ==================================================================== [echo] BUILD SUCCESSFUL Total time: 13 seconds Remove any old dspace Tomcat files: rm -rf /home/dspace/tomcat/webapps/*dspace Copy over new .war files: cp /home/dspace/dspace-1.3.2-source/build/*.war /home/dspace/tomcat/webapps Restart tomcat and the handle server su - root service tomcat start Using CATALINA_BASE: /home/dspace/tomcat Using CATALINA_HOME: /home/dspace/tomcat Using CATALINA_TMPDIR: /home/dspace/tomcat/temp Using JRE_HOME: /usr/java/jdk service handle start exit Hurray DSpace 1.3.2 works :-))) I found I needed to update the customised styles.css.jsp in jsp/local so that it included the new additions introduced in the default styles.css.jsp as supplied with the DSpace 1.3.2 distribution. I then noticed that W3C XHTML validation came up with errors. This was due to the customised jsp's I originally created in DSpace 1.2.2 having been copied into subsequent versions of DSpace. I took the relevant default jsp's that came with DSpace 1.3.2 and customised them to suit our in-house theme. I also had to change the tags used in the news and sidebar pages from uppercase to lowercase. As a result of these changes validation now works properly. <a href="#menu">Return to Menu</a> <a name="seventeen"></a>17) Providing OAI access to DSpace For an introduction to OAI for beginners please select this <a href="http://www.oaforum.org/tutorial/english/page1.htm">link</a>. For a guide to configuring OAI with DSpace please select this <a href="http://dspace.org/technology/system-docs/application.html#oai">link</a>. In order to enable OAI access to DSpace I followed this procedure: As root stop the tomcat and handle servers: su - root service tomcat stop service handle stop exit As user dspace copy over dspace-oai.war as follows: cp /home/dspace/dspace-1.3.2-source/build/dspace-oai.war /home/dspace/tomcat/webapps As root restart tomcat and the handle server: su - root service tomcat start service handle start Edit /etc/httpd/conf/workers2.properties Add the following lines to the end of workers2.properties: [uri:/dspace-oai/*] context=/dspace-oai Save the file and restart Apache: service httpd restart Stopping httpd: [ OK ] Starting httpd: [ OK ] On visiting the following URL on our site: http://vle.bromley.ac.uk/dspace-oai/request?verb=Identify the appropriate xml page appears in the browser :-) The repository can now be registered with the <a href="http://www.openarchives.org/data/registerasprovider.html">Open Archives Initiative</a> as a data provider. The base URL of our site for OAI registration purposes was: http://vle.bromley.ac.uk/dspace-oai/request i.e. everything up to the ? is your base url. Once registered with the Open Archives Initiative the repository will be harvested regularly and will be searchable from <a href="http://oaister.umdl.umich.edu/o/oaister/">Oaister</a> (Thanks to Henk Meij for his invaluable advice on getting this working and for pointing me to the appropriate Dspace documentation that I'd missed :-) <a href="#menu">Return to Menu</a> <a name="eighteen"></a>18) Using a commercial wildcard SSL certificate The College uses a wildcard SSL certificate provided by GlobalSign for the bromley.ac.uk domain. In order to harmonise with the other servers in the College I decided to replace the self-signed certificate as created in section 7 above with the College certificate. I logged in as root and backed up the certwork directory to be on the safe side :-) cp -pr /root/certwork /root/certworkback I moved to the directory certwork into which I had already uploaded the .pfx file provided to me. cd /root/certwork I ran the following command to extract the server key and relevant certificates from the .pfx file: openssl pkcs12 -in 2006BromleyWildforMoodle.pfx -out outputfile.txt -nodes enter password: xxxxxxx The password used above was provided along with the .pfx file. The file outputfile.txt contained the server private key and the certificates in plain text format. I extracted the key and certificate files in turn from outputfile.txt The first item in the outputfile was the server key. I cut and pasted everything from -----BEGIN RSA PRIVATE KEY ----- to -----END RSA PRIVATE KEY----- inclusive into a file called server.key less outputfile.txt pico server.key The second item in the outputfile was the Bromley Wild server certificate. I cut and pasted everything from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE----- inclusive into a file called server.crt less outputfile.txt pico server.crt The remaining three items in the outputfile were the GloabalSign certificates. I cut and pasted each of the remaining certificates in turn as shown below: less outputfile.txt pico gs-root.crt less outputfile.txt pico gs-primserver.crt less outputfile.txt pico gs-serversign.crt I generated a public Certificate Signing Request (CSR) for the server as follows: openssl req -new -key server.key -out server.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [GB]:GB State or Province Name (full name) [Berkshire]:Kent Locality Name (eg, city) [Newbury]:Bromley Organization Name (eg, company) [My Company Ltd]:Bromley College Organizational Unit Name (eg, section) []:Bromley College Common Name (eg, your name or your server's hostname) []:vle.bromley.ac.uk Email Address []:root@vle.bromley.ac.uk Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: This created the file server.csr I created an "insecure" server key to prevent Apache asking for a password every time I tried to restart the httpd process: openssl rsa -in server.key -out server.key.insecure writing RSA key I copied over the relevant keys, CSR's and certificates ready for Apache to use: cp gs* /etc/httpd/conf/ssl.crt cp server.crt /etc/httpd/conf/ssl.crt cp server.csr /etc/httpd/conf/ssl.csr cp server.key.insecure /etc/httpd/conf/ssl.key/server.key To be on the safe side I also changed the permissions of the above files to 600 as shown below: chmod 600 /etc/httpd/conf/ssl.key/* chmod 600 /etc/httpd/conf/ssl.crt/* chmod 600 /etc/httpd/conf/ssl.csr/* I then restarted Apache: [root@cd certwork]# service httpd restart Stopping httpd: [ OK ] Starting httpd: [ OK ] When I visited DSpace from a browser the new certificate was successfully presented for acceptance :-) <a href="#menu">Return to Menu</a> <a name="twenty"></a>20) Upgrading to DSpace 1.4 (failed) Please do not follow these instructions as I have been unable so far to successfully upgrade DSpace 1.3.2 to DSpace 1.4 on a CentOS 4.3 platform. The information below is intended to document the process I followed to help myself and the community: After several failed upgrades from DSpace 1.3.2 on CentOS 4.3 I decided to try again one last time. I rebuilt the testvle server from the vle server to remove all traces of DSpace 1.4 I tried out DSpace 1.3.2 on the testvle server and it worked correctly. As regards the versions of Java and PostgreSQL: echo $JAVA_HOME /usr/java/jdk /usr/java/jdk/bin/java -version java version "1.5.0_04" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05) Java HotSpot(TM) Server VM (build 1.5.0_04-b05, mixed mode rpm -q postgresql postgresql-7.4.13-2.RHEL4.1 I then followed the following upgrade procedure exactly As user dspace pwd /home/dspace tar -xzvf dspace-1.4-source.tar.gz (I downloaded the above file freshly from a different mirror) cd dspace-1.4-source cd lib rm -rf pg74* (to delete any old pg74 .jar files) lynx http://jdbc.postgresql.org/download.html (downloaded pg74.216.jdbc2.jar) cd ../config rm dspace.cfg cp /home/dspace/custom/dspace.cfg . (dspace.cfg was the default file taken from the dspace 1.4 source and edited to include the relevant settings for the testvle server. I deliberately did not copy over custom jsp's to try and keep things as close to the default as possible.) cd .. ant -Dconfig=/home/dspace/config/dspace.cfg update Buildfile: build.xml compile: [mkdir] Created dir: /home/dspace/dspace-1.4-source/build/classes [javac] Compiling 232 source files to /home/dspace/dspace-1.4-source/build/classes [javac] Note: * uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. install_code: [copy] Copying 7 files to /home/dspace/bin [copy] Copying 14 files to /home/dspace/lib [jar] Building jar: /home/dspace/lib/dspace.jar build_wars: [copy] Copying 1 file to /home/dspace/dspace-1.4-source/build [mkdir] Created dir: /home/dspace/dspace-1.4-source/jsp/local [mkdir] Created dir: /home/dspace/dspace-1.4-source/build/jsp [copy] Copying 216 files to /home/dspace/dspace-1.4-source/build/jsp [copy] Copying 1 file to /home/dspace/dspace-1.4-source/build/classes [war] Building war: /home/dspace/dspace-1.4-source/build/dspace.war [copy] Copying 1 file to /home/dspace/dspace-1.4-source/build [war] Building war: /home/dspace/dspace-1.4-source/build/dspace-oai.war update: [copy] Copying 1 file to /home/dspace/config [echo] [echo] ==================================================================== [echo] Copied language packs into /home/dspace/config [echo] [echo] ==================================================================== [echo] Updated Web application (.war) files are in the 'build' directory. [echo] [echo] * Stop your Web servlet container (Tomcat, Jetty, Resin etc.) [echo] [echo] * If you're using Tomcat, you need delete the directories [echo] corresponding to the old .war files. For example, if dspace.war [echo] is installed in CATALINA_HOME/webapps/dspace.war, you should [echo] delete the CATALINA_HOME/webapps/dspace directory. Otherwise, [echo] Tomcat will continue to use the old code in that directory. [echo] [echo] * Copy the new dspace.war and dspace-oai.war from the 'build' [echo] directory over the old ones [echo] [echo] * Start up your Web servlet container again. [echo] ==================================================================== [echo] BUILD SUCCESSFUL Total time: 13 seconds su - root service postgresql start Starting postgresql service: [ OK ] exit As user dspace psql -f etc/database_schema_13-14.sql dspace -h localhost Password: CREATE SEQUENCE CREATE SEQUENCE psql:etc/database_schema_13-14.sql:61: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "group2group_pkey" for table "group2group" CREATE TABLE psql:etc/database_schema_13-14.sql:77: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "group2groupcache_pkey" for table "group2groupcache" CREATE TABLE CREATE SEQUENCE CREATE SEQUENCE CREATE SEQUENCE psql:etc/database_schema_13-14.sql:93: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "metadataschemaregistry_pkey" for table "metadataschemaregistry" psql:etc/database_schema_13-14.sql:93: NOTICE: CREATE TABLE / UNIQUE will create implicit index "metadataschemaregistry_namespace_key" for table "metadataschemaregistry" CREATE TABLE psql:etc/database_schema_13-14.sql:103: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "metadatafieldregistry_pkey" for table "metadatafieldregistry" CREATE TABLE psql:etc/database_schema_13-14.sql:114: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "metadatavalue_pkey" for table "metadatavalue" CREATE TABLE CREATE INDEX CREATE INDEX CREATE INDEX INSERT 41400 1 INSERT 0 66 INSERT 0 716 DROP TABLE CREATE VIEW setval -------- 66 (1 row) setval -------- 716 (1 row) setval -------- 1 (1 row) DROP TABLE ALTER TABLE UPDATE 281 ALTER TABLE psql:etc/database_schema_13-14.sql:167: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "checksum_results_pkey" for table "checksum_results" CREATE TABLE psql:etc/database_schema_13-14.sql:187: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "most_recent_checksum_pkey" for table "most_recent_checksum" CREATE TABLE psql:etc/database_schema_13-14.sql:202: NOTICE: CREATE TABLE will create implicit sequence "checksum_history_check_id_seq" for "serial" column "checksum_history.check_id" psql:etc/database_schema_13-14.sql:202: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "checksum_history_pkey" for table "checksum_history" CREATE TABLE INSERT 42223 1 INSERT 42224 1 INSERT 42225 1 INSERT 42226 1 INSERT 42227 1 INSERT 42228 1 INSERT 42229 1 INSERT 42230 1 INSERT 42231 1 INSERT 0 281 UPDATE 45 INSERT 0 281 UPDATE 281 ALTER TABLE CREATE SEQUENCE psql:etc/database_schema_13-14.sql:355: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "itemsbysubject_pkey" for table "itemsbysubject" CREATE TABLE CREATE INDEX CREATE VIEW CREATE VIEW /home/dspace/bin/index-all Creating browse index Indexing all Items in DSpace.... ... Done Creating search index Done with indexing rm -rf /home/dspace/tomcat/webapps/*dspace* cp /home/dspace/dspace-1.4-source/build/*.war /home/dspace/tomcat/webapps su - root service httpd start Starting httpd: [ OK ] service tomcat start Using CATALINA_BASE: /home/dspace/tomcat Using CATALINA_HOME: /home/dspace/tomcat Using CATALINA_TMPDIR: /home/dspace/tomcat/temp Using JRE_HOME: /usr/java/jdk On visiting the testvle dapace homepage I got exactly the same problem as with previous DSpace 1.4 upgrade attempts. The default header, footer and navigation bars were correctly displayed, but the centre pane contained the error message: Internal System Error The system has experienced an internal error. Please try to do what you were doing again, and if the problem persists, please contact us so we can fix the problem. DSpace at Bromley College administration contact details: By e-mail: dspace-help@vle.bromley.ac.uk Or telephone: 020 8295 7000 x7144 Go to the DSpace home page Clicking on a link on the Navigation bar produced the following error page: HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception java.lang.NoClassDefFoundError org.dspace.app.webui.util.UIUtil.obtainContext(UIUtil.java:118) org.dspace.app.webui.servlet.DSpaceServlet.processRequest(DSpaceServlet.java:132) org.dspace.app.webui.servlet.DSpaceServlet.doGet(DSpaceServlet.java:99) javax.servlet.http.HttpServlet.service(HttpServlet.java:689) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) note The full stack trace of the root cause is available in the Apache Tomcat/5.5.9 logs. Richard Jones suggested the following: "According to the errors thrown by pages using servlets (the index page is an exception in DSpace in the way that it is processed), there is a missing class in your DSpace instance. Line 118 of UIUtil is: int[] groupIDs = AuthenticationManager.getSpecialGroups(c, request); Presumably, then, the AuthenticationManager class is missing, but how the code compiled without this class is a mystery to me! Can you check that there exists a class/source file org.dspace.eperson.AuthenticationManager in the following locations: a) your source code that you built from (in src/) b) the built, but as yet undeployed classes (in build/classes) c) inside the live dspace.jar file (run something like 'jar tf dspace.jar | grep AuthenticationManager') Perhaps there has something gone wrong in the build, most likely between b and c above." To help debug I tried the locate command: updatedb locate AuthenticationManager /home/dspace/tomcat/webapps/dspace-oai/WEB-INF/classes/org/dspace/eperson/AuthenticationManager.class /home/dspace/tomcat/webapps/dspace/WEB-INF/classes/org/dspace/eperson/AuthenticationManager.class /home/dspace/dspace-1.4-source/src/org/dspace/eperson/AuthenticationManager.java /home/dspace/dspace-1.4-source/build/classes/org/dspace/eperson/AuthenticationManager.class I then tried: [dspace@testvle lib]$ jar tf dspace.jar | grep AuthenticationManager org/dspace/eperson/AuthenticationManager.class 12th August 2006: Several people (Richard Jones and Jonathan Champ) have suggested clearing the Tomcat work cache. I have tried this without success as shown below: su - root Password: This is vle server B service tomcat stop Using CATALINA_BASE: /home/dspace/tomcat Using CATALINA_HOME: /home/dspace/tomcat Using CATALINA_TMPDIR: /home/dspace/tomcat/temp Using JRE_HOME: /usr/java/jdk exit rm -rf /home/dspace/tomcat/work/* cd /home/dspace/dspace-1.4-source !ant ant -Dconfig=/home/dspace/config/dspace.cfg update BUILD SUCCESSFUL rm -rf /home/dspace/tomcat/webapps/*dspace* cp /home/dspace/dspace-1.4-source/build/*.war /home/dspace/tomcat/webapps su - root service tomcat start Using CATALINA_BASE: /home/dspace/tomcat Using CATALINA_HOME: /home/dspace/tomcat Using CATALINA_TMPDIR: /home/dspace/tomcat/temp Using JRE_HOME: /usr/java/jdk No luck problem is still there: java.lang.NoClassDefFoundError org.dspace.app.webui.util.UIUtil.obtainContext(UIUtil.java:118) Another problem I've noticed this morning is with the filter-media script: /home/dspace/bin/index-all Creating browse index Indexing all Items in DSpace.... ... Done Creating search index Done with indexing /home/dspace/bin/filter-media Applying Media Filters Exception in thread "main" java.lang.ClassCastException: [Ljava.lang.Object; at org.dspace.app.mediafilter.MediaFilterManager.main(MediaFilterManager.java:160) When filter-media is run on 1.3.2 it is fine, but on the 1.4 upgrade it fails. <a href="#menu">Return to Menu</a> <a name="twentyone"></a>21) Re-installing DSpace 1.4 (success) Wednesday 16th August 2006: I have undertaken a fresh install of DSpace 1.4 on the vle server and have copied over all the relevant content from the 1.3.2 installation. DSpace 1.4 now works fine with all the path information, plus ant, postgresql, java, tomcat, all exactly the same as for the failed upgrade from 1.3.2 to 1.4 Before starting the reinstall it is vital to have a full backup of the entire contents of the directories /home/dspace and the /var/lib/pgsql/data as used with DSpace 1.3.2. The process I followed is as below: su - root service tomcat stop Using CATALINA_BASE: /home/dspace/tomcat Using CATALINA_HOME: /home/dspace/tomcat Using CATALINA_TMPDIR: /home/dspace/tomcat/temp Using JRE_HOME: /usr/java/jdk service postgresql stop Stopping postgresql service: [ OK ] exit The following commands pre-suppose that all important files from DSpace 1.3.2 have already been copied into a new directory /home/dspace/custom or are available via rsync from our backup server. As user dspace remove old installation and copy over custom files: cd /home/dspace rm -rf bin rm -rf config rm -rf handle-server/ rm -rf history/ rm -rf lib/ rm -rf log* rm -rf reports rm -rf search cp custom/dspace-1.4-source.tar.gz . tar -xzvf dspace-1.4-source.tar.gz rm -