Server-side Installation of Evergreen SoftwareThis section describes installation of the Evergreen server-side software and its associated components. Installation, configuration, testing and verification of the software is straightforward if you follow some simple directions.OverviewInstalling, configuring and testing the Evergreen server-side software is straightforward with the current stable software release. See for instructions tailored to installing on some particular distributions of the Linux operating system. Earlier software distributions are described in .The current version of the Evergreen server-side software runs as a native application on any of several well-known Linux distributions (e.g., Ubuntu and Debian). It does not currently run as a native application on the Microsoft Windows operating system (e.g., WindowsXP, WindowsXP Professional, Windows7), but the software can still be installed and run on Windows via a so-called virtualized Unix-guest Operating System (using, for example, "VirtualBox", or "VMware", or "VirtualPC" to emulate a Linux environment). It can also be installed to run on other Linux systems via virtualized environments (using, for example, "VirtualBox" or "VMware"). More information on virtualized environments can be found in .Installation of some sub-components of the Evergreen server-side software is mentioned only in abbreviated form in this section. More detailed information is available in and .Finally, installation of the Evergreen Staff Client software is reviewed in . Evergreen Software DependenciesThe Evergreen server-side software has dependencies on particular versions of certain major software sub-components. Successful installation of Evergreen software requires that software versions agree with those listed here:
Current Stable Software ReleaseThe current stable release of Evergreen is version 1.6.0.7. Instructions for installing, configuring and testing that version on the Ubuntu or DebianLinux systems are found in .This release of Evergreen software is dependent on the Open Service Request Framework (OpenSRF). The current stable release of OpenSRF is version 1.2.2. Instructions for installing, configuring and testing that version are found in .Previous Software ReleasesEarlier releases of Evergreen are also available. Instructions for installing, configuring and testing earlier versions are found in .The next most recent previous release of Evergreen is version 1.4.0.6. Instructions for installing, configuring and testing that version are found in .The accompanying previous release of OpenSRF is version 1.0.7. Instructions for installing, configuring and testing that version are found in .Installing Server-Side SoftwareThis section describes the installation of the major components of Evergreen server-side software.As far as possible, you should perform the following steps in the exact order given since the success of many steps relies on the successful completion of earlier steps. You should make backup copies of files and environments when you are instructed to do so. In the event of installation problems those copies can allow you to back out of a step gracefully and resume the installation from a known state. See for further information.Of course, after you successfully complete and test the entire Evergreen installation you should take a final snapshot backup of your system(s). This can be the first in the series of regularly scheduled system backups that you should probably also begin.Installing OpenSRF 1.2.2 On Ubuntu or DebianThis section describes the installation of the latest version of the Open Service Request Framework (OpenSRF), a major component of the Evergreen server-side software, on Ubuntu or Debian systems. Evergreen software is integrated with and depends on the OpenSRF software system.Follow the steps outlined here and run the specified tests to ensure that OpenSRF is properly installed and configured. Do not continue with any further Evergreen installation steps until you have verified that OpenSRF has been successfully installed.The following steps have been tested on the x86 (32-bit) and x86-64 (64-bit) platforms. OpenSRF 1.2.2 has been tested on Debian Etch (4.0), Debian Lenny, Ubuntu Hardy Heron (8.04), and Ubuntu Intrepid Ibex (8.10).In the following instructions, you are asked to perform certain steps as either the root user, the opensrf user, or the postgres user.Debian -- To become the root user, issue the command su - and enter the password of the root user.Ubuntu -- To become the root user, issue the command sudo su - and enter the password of the root user.To switch from the root user to a different user, issue the command su - USERNAME. For example, to switch from the root user to the opensrf user, issue the command su - opensrf. Once you have become a non-root user, to become the root user again, simply issue the command exit".Add the OpenSRF UserAs the root user, add the opensrf user to the system. The default shell for the new user is automatically set to /bin/bash to inherit a reasonable environment:Download and Unpack Latest OpenSRF VersionAs the opensrf user, download and extract the latest version of OpenSRF. The latest version can be found here: The new directory /home/opensrf/OpenSRF-1.2.2 will be created.Install Prerequisites to Build OpenSRFIn this section you will install and configure a set of prerequisites that will be used to build OpenSRF. In a following step you will actually build the software using the make utility.As the root user, enter the commands show below to build the prerequisites from the software distribution that you just downloaded and unpacked. Remember to replace [DISTRIBUTION] in the example with the keyword corresponding to the actual Linux distribution listed in the "Keywords" figure below.
ZZZ-REVIEWADD INFO FOR OTHER LINUX DISTRIBUTIONS ADD INFO FOR OTHER LINUX DISTRIBUTIONS This will install a number of packages on the system that are required by OpenSRF, including some Perl modules from CPAN. You can say No to the initial CPAN configuration prompt to allow it to automatically configure itself to download and install Perl modules from CPAN. The CPAN installer will ask you a number of times whether it should install prerequisite modules - say Yes.Configure OpenSRFAs the opensrf user, return to the OpenSRF build directory and use the configure utility to prepare for the next step of compiling and linking the software. You can include the and configuration options if you wish to include support for Python and Java, respectively:Compile, Link and Install OpenSRFAs the root user, return to the OpenSRF build directory and use the make utility to compile, link and install OpenSRF:Update the System Dynamic Library PathAs the root user, you must update the system dynamic library path to make your system recognize the newly installed libraries. Do this by creating the new file /etc/ld.so.conf.d/osrf.conf containing a new library path, then run the command ldconfig to automatically read the file and modify the system dynamic library path:Define Public and Private OpenSRF DomainsDefine your public and private OpenSRF domains. For security purposes, OpenSRF uses Jabber domains to separate services into public and private realms. Throughout these instructions, we will use the example domains public.localhost for the public domain and private.localhost for the private domain. On a single-server system, the easiest way to define public and private domains is to define separate host names by adding entries to the file /etc/hosts.As the root user, edit the file /etc/hosts and add the following entries for our example domains:Change File OwnershipsAs the root user, change the ownership of files installed in the directory /openils to the opensrf user:Stop the ejabberd ServiceAs the root user, stop the ejabberd service:If ejabberd reports that it is already stopped, it may have run into a problem starting back at the installation stage. One possible fix is to kill any remaining beam and epmd processes, then edit the configuration file /etc/ejabberd/ejabberd.cfg to hardcode a domain:Edit the ejabberd configurationAs the root user, edit the file /etc/ejabberd/ejabberd.cfg and make the following changes:Change {hosts, ["localhost"]}. to {hosts, ["localhost", "private.localhost", "public.localhost"]}.Change {max_user_sessions, 10}. to {max_user_sessions, 10000}. If you see something like this instead: {access, max_user_sessions, [{10, all}]}., then change it to {access, max_user_sessions, [{10000, all}]}.Change all three occurrences of max_stanza_size to 2000000.Change both occurrences of maxrate to 500000.Comment out the line {mod_offline, []} by placing two % comment signs in front.Restart the ejabberd serviceAs the root user, restart the ejabberd service to test the configuration changes and to register your users:Register router and ejabberd usersOn each domain, you need two ejabberd users to manage the OpenSRF communications:a router user, to whom all requests to connect to an OpenSRF service will be routed; this ejabberd user must be named routeran opensrf user, which clients use to connect to OpenSRF services; this user can be named anything you like, but we will use opensrf in our examplesAs the root user, use the ejabberdctl utility to register your ejabber users router and opensrf for the OpenSRF router service on each domain. The users should have different passwords on each domain. These users will correspond to those configured in the file /openils/conf/opensrf_core.xml:Create configuration filesAs the opensrf user, use the example templates to create the configuration files /openils/conf/opensrf_core.xml and /openils/conf/opensrf.xml:Edit opensrf_core.xmlEdit the file /openils/conf/opensrf_core.xml to change the ejabberd usernames and passwords as follows.The following example uses common XPath syntax on the left-hand side to indicate the approximate position needing changes within the XML file.You also need to specify the domains from which OpenSRF will accept and to which OpenSRF will make connections. If you are installing OpenSRF on a single server and using the private.localhost / public.localhost domains, these will already be set to the correct values. Otherwise, search and replace to match your values.Modify the file opensrf.xmlAs the opensrf user, edit the file /openils/conf/opensrf.xml to set the location of the persistent database in the dbfile element near the end of the file:Create Configuration Files for Users Needing "srfsh"In this section you will set up a special configuration file for each user who will need to run the "srfsh" (pronounced surf shell) utility.The software installation will automatically create "srfsh". This is a command line diagnostic tool for testing and interacting with the OpenSRF network software. It will be used in a future step to complete and test the Evergreen installation. See for further information.As the root user, copy the short sample configuration file /openils/conf/srfsh.xml.example to the file .srfsh.xml (note the leading dot!) in the home directory of each user who will use "srfsh". Finally, edit each file .srfsh.xml and make the following changes. When you finish, remember to change the owner of the file to match the owner of the home directory.Modify domain to be the router hostname (following our domain examples, private.localhost will give "srfsh" access to all OpenSRF services, while public.localhost will only allow access to those OpenSRF services that are publicly exposed).Modify username and password to match the opensrf Jabber user for the chosen domainModify logfile to be the full path for a log file to which the user has write accessModify loglevel as needed for testingModify Environmental Variable PATH for opensrf UserAs the opensrf user, modify the environmental variable PATH by adding a new file path to the opensrf user's shell configuration file .bashrc:Starting OpenSRFAs the root user, start the ejabberd and memcached services:Finally, as the opensrf user, start OpenSRF:You can also start Evergreen without the -l flag, but osrf_ctl.sh must know the fully qualified domain name for the system on which it will execute. That hostname may have been specified in the configuration file opensrf.xml, which you configured in a previous step.Testing connections to OpenSRFOnce you have installed and started OpenSRF, as the root user, test your connection to OpenSRF using the "srfsh" utility and trying to call the add method on the OpenSRF math service:ZZZ-REVIEWVERIFY THIS TEST VERIFY THIS TEST For other "srfsh" commands, type help in at the prompt.Stopping OpenSRFAs the opensrf user, stop OpenSRF:Installing Evergreen 1.6.0.7 On Ubuntu or DebianThis section outlines the installation process for the latest stable version of Evergreen.In this section you will download, unpack, install, configure and test the Evergreen system, including the Evergreen server and the PostgreSQL database system. You will make several configuration changes and adjustments to the software, including updates to configure the system for your own locale, and some updates needed to work around a few known issues.The following steps have been tested on the x86 (32-bit) and x86-64 (64-bit) architectures. There may be differences between the Desktop and Server editions of Ubuntu. These instructions assume the Server edition.In the following instructions, you are asked to perform certain steps as either the root user, the opensrf user, or the postgres user.Debian -- To become the root user, issue the command su - and enter the password of the root user.Ubuntu -- To become the root user, issue the command sudo su - and enter the password of the root user.To switch from the root user to a different user, issue the command su - USERNAME. For example, to switch from the root user to the opensrf user, issue the command su - opensrf. Once you have become a non-root user, to become the root user again, simply issue the command exit.Installing OpenSRFEvergreen software is integrated with and depends on the Open Service Request Framework (OpenSRF) software system. For further information on installing, configuring and testing OpenSRF, see .Follow the steps outlined in that section and run the specified tests to ensure that OpenSRF is properly installed and configured. Do not continue with any further Evergreen installation steps until you have verified that OpenSRF has been successfully installed.Download and Unpack Latest Evergreen VersionAs the opensrf user, download and extract the latest version of Evergreen. The latest version can be found here: The new directory /home/opensrf/Evergreen-ILS-1.6.0.7 will be created.Install Prerequisites to Build EvergreenIn this section you will install and configure a set of prerequisites that will be used to build Evergreen. In a following step you will actually build the software using the make utility.As the root user, enter the commands show below to build the prerequisites from the software distribution that you just downloaded and unpacked. Remember to replace [distribution] in the example with the keyword corresponding to the actual Linux distribution listed in the "Keywords" figure below.
Keywords Targets for "make" CommandKeywordDescriptiondebian-lennyfor Debian Lenny (5.0), the most recent versiondebian-etchfor Debian Etch (4.0)ubuntu-karmicfor Ubuntu Lucid (10.04) [same as for Karmic]ubuntu-karmicfor Ubuntu Karmic (9.10)ubuntu-intrepidfor Ubuntu Intrepid (8.10)ubuntu-hardyfor Ubuntu Hardy (8.04)ubuntu-gutsyfor Ubuntu Gutsy (7.10)gentoogeneric for Gentoo versionscentosgeneric for Centos versions
ZZZ-REVIEWADD INFO FOR OTHER LINUX DISTRIBUTIONS ADD INFO FOR OTHER LINUX DISTRIBUTIONS (OPTIONAL) Install the PostgreSQL ServerSince the PostgreSQL server is usually a standalone server in multi-server production systems, the prerequisite installer Makefile in the previous step does not automatically install PostgreSQL. If your PostgreSQL server is on a different system, just skip this step.For further information on manually installing PostgreSQL, see .If your PostgreSQL server will be on the same system as your Evergreen software, then as the root user install the required PostgreSQL server packages:PostgreSQL 8.1 is deprecated and will become unsupported in a future Evergreen release, though existing installations upgrading from Evergreen 1.4 or before will continue to work. Please upgrade your PostgreSQL installation soon.ZZZ-REVIEWADD INFO ON HOW TO DETERMINE WHICH VERSION OF POSTGRESQL YOU CURRENTLY HAVEADD INFO ON HOW TO DETERMINE WHICH VERSION OF POSTGRESQL YOU CURRENTLY HAVE(OPTIONAL) Install Perl Modules on PostgreSQL ServerIf PostgreSQL is running on the same system as your Evergreen software, then the Perl modules will automatically be available. Just skip this step.Otherwise, if your PostgreSQL server is running on another system, then as the root user install the following Perl modules on that system:ZZZ-REVIEWADD INFO ON HOW TO INSTALL THE PERL MODULES ADD INFO ON HOW TO INSTALL THE PERL MODULES ZZZ-REVIEWADD INFO ON HOW TO VERIFY THAT THE PERL MODULES ARE INSTALLED ADD INFO ON HOW TO VERIFY THAT THE PERL MODULES ARE INSTALLED Update the System Dynamic Library PathAs the root user, you must update the system dynamic library path to make your system recognize the newly installed libraries. Do this by creating the new file /etc/ld.so.conf.d/eg.conf containing two new library paths, then run the command ldconfig to automatically read the file and modify the system dynamic library path:(OPTIONAL) Restart the PostgreSQL ServerIf PostgreSQL is running on the same system as the rest of Evergreen, as the root user you must restart the PostgreSQL server to avoid a problem where the library plperl.so cannot be found. If your PostgreSQL server is running on another system, just skip this step.ZZZ-REVIEWADD INFO ON OTHER VERSIONS OF POSTGRESQL ADD INFO ON OTHER VERSIONS OF POSTGRESQL Where PGSQL_VERSION is your installed PostgreSQL version (e.g. 8.3).Configure EvergreenAs the opensrf user, return to the Evergreen build directory and use the configure utility to prepare for the next step of compiling and linking the software:Compile, Link and Install EvergreenIn this step you will actually compile, link and install Evergreen and the default Evergreen Staff Client.As the root user, return to the Evergreen build directory and use the make utility as shown below. The Staff Client will also be automatically built, but you must remember to set the variable STAFF_CLIENT_BUILD_ID to match the version of the Staff Client you will use to connect to the Evergreen server.For further information on manually building the Staff Client, see .To complete the Staff Client installation, as the root user create a symbolic link named server in the head of the Staff Client directory /openils/var/web/xul that points to the subdirectory /server of the new Staff Client build:Copy the OpenSRF Configuration FilesAs the root user, copy the example OpenSRF configuration files into place. This replaces the configuration files that you set up in a previous step when you installed and tested OpenSRF. You should also create backup copies of the old files for troubleshooting purposes. Finally, change the ownership on the installed files to the opensrf user:Create and Configure PostgreSQL DatabaseAs the postgres user on your PostgreSQL server, create the Evergreen database.In the commands below, remember to adjust the path of the contrib repository to match your PostgreSQL server layout. For example, if you built PostgreSQL from source the path would be /usr/local/share/contrib; if you installed the PostgreSQL 8.3 server packages on Ubuntu 8.04, the path would be /usr/share/postgresql/8.3/contrib/.Create and configure the databaseAs the postgres user on the PostgreSQL system create the PostgreSQL database, then set some internal paths:Where PGSQL_VERSION is your installed PostgreSQL version (e.g. 8.3).Create new Evergreen superuserAs the postgres user on the PostgreSQL system, create the new database evergreen user and assign a password:Where MYNEWPASSWORD is the password chosen.Create Database SchemaAs the root user, create the database schema and configure your system with the corresponding database authentication details for the evergreen database user that you created in the previous step.Enter the following commands and replace HOSTNAME, PORT, PASSWORD and DATABASENAME with appropriate values.Where, on most systems, HOSTNAME will be localhost, PORT will be 5432, and PASSWORD and DATABASENAME will be those assigned when PostgreSQL was installed in the previous step.If you are entering the above command on a single line, do not include the \ (backslash) characters. If you are using the bash shell, these should only be used at the end of a line at a bash prompt to indicate that the command is continued on the next line.Modify the Apache ConfigurationThe Apache configuration must be updated in several ways to support Evergreen.Configure the Apache ServerEnable some built-in Apache modules with the utility a2enmod, and install some additional Apache configuration files. As the root user, enable some modules in the Apache server, then copy the new configuration files to the Apache server directories:Create a Security Certificate (SSL Key)Create a new SSL key for the Apache server with the command openssl. For a public production server you should configure or purchase a signed SSL certificate, but for now you can just use a self-signed certificate and accept the warnings in the Staff Client and browser during testing and development:This is only a temporary measure to expedite testing. You must get a proper SSL certificate for a public production system.For further information on getting a proper SSL certificate, see .Modify the Apache Configuration FileSeveral changes are needed in the new Apache configuration file /etc/apache2/sites-available/eg.conf. As the root user, edit the file and make the following changes:Comment out the line Allow from 10.0.0.0/8, then uncomment the line Allow from all.This change allows access to your configuration CGI scripts from any workstation on any network. This is only a temporary change to expedite testing and should be removed after you have finished and successfully tested the Evergreen installation.You must remove these changes after testing is completed. See for further details on removing this change after the Evergreen installation is complete.Comment out the line Listen 443, since it conflicts with the same declaration in the configuration file: /etc/apache2/ports.conf. Debian Etch users should not do this.ZZZ-REVIEWADD INFO ON WHY DEBIAN ETCH USERS SHOULD NOT DO THIS ADD INFO ON WHY DEBIAN ETCH USERS SHOULD NOT DO THIS The following updates are needed to allow the logs to function properly, but it may break other Apache applications on your server.For the Linux distributions Ubuntu Hardy or Debian Etch, as the root user, edit the Apache configuration file /etc/apache2/apache2.conf and change the phrase: User www-data to the phrase: User opensrf.For the Linux distributions Ubuntu Karmic or Ubuntu Lucid or Debian Lenny, as the root user, edit the Apache configuration file /etc/apache2/envvars and change the phrase: export APACHE_RUN_USER=www-data to the phrase: export APACHE_RUN_USER=opensrf.As the root user, edit the Apache configuration file /etc/apache2/apache2.conf and add the lines KeepAliveTimeout 1 and MaxKeepAliveRequests 100, or modify any existing lines.(OPTIONAL) Performance Modifications for ApacheSome further configuration changes to Apache may be necessary for busy systems. These changes increase the number of Apache server processes that are started to support additional browser connections.As the root user, edit the Apache configuration file /etc/apache2/apache2.conf, locate and modify the section related to prefork configuration to suit the load on your system.Enable the Evergreen Web SiteFinally, as the root user, execute the following Apache configuration commands to disable the default It Works web page and to enable the Evergreen web site:Modify the OpenSRF Configuration FileAs the opensrf user, edit the OpenSRF configuration file /openils/conf/opensrf_core.xml to update the Jabber usernames and passwords, and to specify the domain from which we will accept and to which we will make connections.If you are installing Evergreen on a single server and using the private.localhost / public.localhost domains, these will already be set to the correct values. Otherwise, search and replace to match your customized values.The following example uses common XPath syntax on the left-hand side to indicate the approximate position needing changes within the XML file:ZZZ-REVIEWADD A BETTER DIAGRAM HERE ADD A BETTER DIAGRAM HERE Create Configuration Files for Users Needing "srfsh"The software installation will automatically create a utility named "srfsh" (surf shell). This is a command line diagnostic tool for testing and interacting with the OpenSRF network software. It will be used in a future step to complete and test the Evergreen installation. See for further information.In this section you will set up a special configuration file for each user who will need to run the utility. Copy the short sample configuration file /openils/conf/srfsh.xml.example to the file .srfsh.xml (note the leading dot!) in the home directory of each user who will use "srfsh". Finally, edit each users' .srfsh.xml file and make the following changes:Modify domain to be the router hostname (following our domain examples, private.localhost> will give "srfsh" access to all OpenSRF services, while public.localhost will only allow access to those OpenSRF services that are publicly exposed).Modify username and password to match the opensrf Jabber user for the chosen domainModify logfile to be the full path for a log file to which the user has write accessModify loglevel as needed for testingModify the OpenSRF EnvironmentAs the opensrf user, change the permissions of .cgi files in the directory /openils/var/cgi-bin to executable, then modify the shell configuration file ~/.bashrc for opensrf by adding a Perl environmental variable. Finally, execute the shell configuration file to load the new variables into your current environment.In a multi-server environment, you must add any modifications to ~/.bashrc to the top of the file before the line [ -z "$PS1" ] && return . This will allow headless (scripted) logins to load the correct environment.(OPTIONAL) Enabling and Disabling Language LocalizationsCurrent versions of Evergreen (after version 1.4) are bundled with support for a number of languages beyond American English (en-US). The translated interfaces are split between static files that are automatically installed with Evergreen, and dynamic labels that can be stored in the Evergreen database. Evergreen is installed with additional SQL files that contain translated dynamic labels for a number of languages, and to make the set of translated labels available in all interfaces. Only a few steps are required to enable or disable one or more languages.Enabling a LocalizationTo enable the translated labels for a given language to display in Evergreen, just populate the database with the translated labels and enable the localization. The following example illustrates how to enable Canadian French (fr-CA) support in the database. These same steps can be used with any of the languages bundled with Evergreen, or you can create and add your own localization.The translated labels for each locale are stored in SQL files named "950.data.seed-values-xx-YY.sql" where "xx-YY" represents the locale code for the translation. Load the translated labels into the Evergreen database using the command psql, substituting your user, host and database connection information accordingly:Ensure the locale is enabled in the Evergreen database by using the utility psql to check for the existence of the locale in the table config.i18n_locale:As shown in the following example, if one row of output is returned, then the locale is already enabled:If zero rows of output are returned, then the locale is not enabled:To enable a locale, use psql to insert a row into the table config.i18n_locale as follows:Disabling a LocalizationYou might not want to offer all of the localizations that are preconfigured in Evergreen. If you choose to disable the dynamic labels for a locale, just delete those entries from the table config.i18n_locale using the psql utility:Starting EvergreenAs the root user, start the ejabberd and memcached services (if they are not already running):As the opensrf user, start Evergreen.Use the flag -l to force Evergreen to use localhost (your current system) as the hostname. Using the start_all option will start the OpenSRF router, Perl services, and C services:You can also start Evergreen without the flag, but the osrf_ctl.sh utility must know the fully qualified domain name for the system on which it will execute. That hostname may have been specified in the configuration file opensrf.xml, which you configured in a previous step.Execute the following command to determine the fully qualified domain name of your system:ZZZ-REVIEWADD EXPLANATION FOR CONFIGURING "opensrf.xml" ADD EXPLANATION FOR CONFIGURING "opensrf.xml" If you receive an error message similar to osrf_ctl.sh: command not found, then your environment variable PATH does not include the directory /openils/bin. As the opensrf user, edit the configuration file /home/opensrf/.bashrc and add the following line: export PATH=$PATH:/openils/binIf you receive an error message similar to Can't locate OpenSRF/System.pm in @INC ... BEGIN failed--compilation aborted, then your environment variable PERL5LIB does not include the directory /openils/lib/perl5. As the opensrf user, edit the configuration file /home/opensrf/.bashrc and add the following line: export PERL5LIB=$PERL5LIB:/openils/lib/perl5As the opensrf user, generate the Web files needed by the Staff Client and catalog, and calculate the proximity of locations in the Organizational Unit tree (which allows Holds to work properly).You must do this the first time you start Evergreen, and after making any changes to the library hierarchy in the configuration file config.cgi.ZZZ-REVIEWADD RESULTS OF TESTS FROM "autogen.sh" ADD RESULTS OF TESTS FROM autogen.shAs the root user, restart the Apache Web server:If the Apache Web server was running when you started the OpenSRF services, you might not be able to successfully log in to the OPAC or Staff Client until the Apache Web server is restarted.Testing the InstallationThis section describes several simple tests you can perform to verify that the Evergreen server-side software has been installed and configured properly and is running as expected.Testing Connections to EvergreenOnce you have installed and started Evergreen, test your connection to Evergreen. As the opensrf user start the "srfsh" application and try logging onto the Evergreen server using the default administrator username and password. Following is sample output generated by executing that script after a successful Evergreen installation:Other Connection Tests with "srfsh"There is another "srfsh" command called math_bench that sends queries to the math servers. Note that the opensrf.math and opensrf.dbmath must be running for this command to work:The first argument is how many sets of 4 queries (+ - * /) are sent to opensrf.math. When the response is successful, you will see the string of + symbols. If the system is not running correctly, you will either get an exception or no result at all.For other "srfsh" commands, type help in at the prompt.If this does not work, try the troubleshooting steps in the following section.Testing with "settings-tester.pl"As the opensrf user, run the script settings-tester.pl to see if it finds any system configuration problems. Following is sample output generated by executing that script after a successful Evergreen installation:Example of execution of settings-tester.pl matches
* OK: Pg language is undefined for reporter base configuration
* OK: Pg language is undefined for reporter base configuration
* OK: Pg language is perl in /opensrf/default/apps/open-ils.storage/language
* OK: pgsql language is C in /opensrf/default/apps/open-ils.cstore/language
* OK: pgsql language is C in /opensrf/default/apps/open-ils.pcrud/language
* OK: pgsql language is C in /opensrf/default/apps/open-ils.reporter-store/language
Checking libdbi and libdbi-drivers
* OK - found locally installed libdbi.so and libdbdpgsql.so in shared library path
Checking hostname
* OK: found hostname 'localhost' in section of opensrf.xml
$
]]>If the output from the script does not help you find the problem, please do not make any further significant changes to your configuration. Follow the steps in the troubleshooting guide in .If you have followed the entire set of installation steps listed here closely, you are probably extremely close to a working system. Gather your configuration files and log files and contact the Evergreen development mailing list for assistance before making any drastic changes to your system configuration.Testing the CatalogBy default, the OPAC will live at the URL http://my.domain.com/opac/.Navigate to this URL and the front page of the OPAC should load. There is a basic text entry field with some extra search options. If you have any problems loading this page, check the Apache error logs. If the page loads but does not function correctly, then check for possible javascript errors. We highty recommend testing with the "Firefox" browser because of the helpful javascript debugging tools.Assuming that the OPAC is functioning and there is data in your database, you can now perform other simple functional tests (e.g., searching the catalog).ZZZ-REVIEWADD OTHER SIMPLE FUNCTIONAL TESTS ADD OTHER SIMPLE FUNCTIONAL TESTS Running the Evergreen Staff ClientRun the Evergreen Staff Client by using the application "XULRunner" (installed automatically and by default with Firefox version 3.0 and later on Ubuntu and Debian distributions).For example, if the source files for the Evergreen installation are in the directory /home/opensrf/Evergreen-ILS-1.6.0.7/, start the Staff Client as follows:Testing the Apache Web ServerOnce you have started Evergreen and confirmed that a basic login attempt works, you can test and start the Apache web server.As the root user, execute the following commands. Note the use of restart to force the new Evergreen modules to be reloaded even if the Apache server is already running. Any problems found with your configuration files should be displayed:Stopping EvergreenAs the opensrf user, stop all Evergreen services by using the following command:You can also stop Evergreen services without the flag, but the osrf_ctl.sh utility must know the fully qualified domain name for the system on which it will execute. That hostname may have been specified in the configuration file opensrf.xml, which you configured in a previous step.ZZZ-REVIEWADD EXPLANATION FOR CONFIGURING "opensrf.xml" ADD EXPLANATION FOR CONFIGURING "opensrf.xml" Post-Installation ChoresThere are a few additional steps to complete after Evergreen has been successfully installed and tested.Remove temporary changes from Apache configuration fileAs the root user, edit the Apache configuration file /etc/apache2/sites-available/eg.conf again and make the following change:Uncomment the line Allow from 10.0.0.0/8, then comment out the line Allow from all. You modified this file in an earlier step as a temporary measure to expedite testing (see for further information). Those changes must now be reversed in order to deny unwanted access to your CGI scripts from users on other public networks. You must secure this for a public production system.Configure a permanent SSL keyIn a previous step, we used the command openssl to temporarily create a new SSL key for the Apache server. For a public production server you should configure or purchase a signed SSL certificate. For further information on getting a proper SSL certificate, see .The temporary SSL key was only created to expedite testing. You must get a proper SSL certificate for a public production system.Set Up Support For ReportsEvergreen reports are extremely powerful, but some configuration is required. See for details.Starting the Reporter DaemonOnce the open-ils.reporter process is running and enabled on the gateway, you can start the reporter daemon. That process periodically checks for requests for new reports or scheduled reports and gets them running.As the opensrf user, start the reporter daemon using the following command:You can also specify other options with this utility: : number of seconds to sleep between checks for new reports to run; defaults to 10 : where to place the lockfile for the process; defaults to /tmp/reporter-LOCK : number of reporter daemon processes to run; defaults to 1 : OpenSRF bootstrap configuration file; defaults to /openils/conf/opensrf_core.xmlStopping the Reporter DaemonTo stop the Reporter daemon, you must kill the process and remove the lockfile. The daemon may have just a single associated process, with a lockfile in the default location.It is possible that several processes are running; see the optional commands in the previous section. As the opensrf user, perform the following commands to stop the Reporter daemon:Organization and Policy EditingAfter installing Evergreen, you will want to make configuration changes to reflect the organizational hierarchy and the policies of your library or libraries. See for further information. Examples of what can be configured include:Adding a branch libraryChanging circulation rules for an existing libraryAdding a new staff position or user groupZZZ-REVIEWADD CONTENT FOR ORGANIZATION AND POLICY EDITING ADD CONTENT FOR ORGANIZATION AND POLICY EDITING Getting a Signed SSL CertificateThis section describes how to get a properly signed SSL certificate.For temporary testing purposes, you can use the command openssl to create a new SSL key for your Apache server. This is just a self-signed certificate and will generate warnings in the Staff Client and browser during testing and development. For a public production server you should configure or purchase a properly signed SSL certificate.ZZZ-REVIEWADD INFO ON HOW TO GET A SIGNED SSL CERTIFICATE ADD INFO ON HOW TO GET A SIGNED SSL CERTIFICATE Installing In Virtualized Unix EnvironmentsEvergreen software currently runs as a native application on any of several well-known Linux distributions (e.g., Ubuntu and Debian). It does not run as a native application on the Windows operating system (e.g., WindowsXP, WindowsXP Professional, Windows7), but the software can be installed and run on Windows via a virtualized Unix-guest Operating System (using, for example, "VirtualBox" or "VMware" to emulate a Linux environment).ZZZ-REVIEWADD CONTENT FOR INSTALLING EVERGREEN IN VIRTUALIZED UNIX ENVIRONMENTS ADD CONTENT FOR INSTALLING EVERGREEN IN VIRTUALIZED UNIX ENVIRONMENTS VirtualBoxZZZ-REVIEWADD CONTENT FOR VirtualBox ADD CONTENT FOR VirtualBox VMwareZZZ-REVIEWADD CONTENT FOR VMware ADD CONTENT FOR VMware VirtualPCZZZ-REVIEWADD CONTENT FOR VirtualPC ADD CONTENT FOR VirtualPC Installing Previous Versions of EvergreenEarlier releases of Evergreen are available. Instructions for installing, configuring and testing earlier versions are found below.The next most recent previous release of Evergreen is version 1.4.0.6. The accompanying previous release of OpenSRF is version 1.0.7.Installing Evergreen 1.4.0.6 On Ubuntu or DebianThis section outlines the installation process for the previous version 1.4.0.6 of Evergreen.In this section you will download, unpack, install, configure and test the Evergreen system, including the Evergreen server and the PostgreSQL database system. You will make several configuration changes and adjustments to the software, including updates to configure the system for your own locale, and some updates needed to work around a few known issues.The following steps have been tested on the x86 (32-bit) and x86-64 (64-bit) architectures. There may be differences between the Desktop and Server editions of Ubuntu. These instructions assume the Server edition.If you are starting with a clean install of Ubuntu or Debian, you are strongly recommended not to install the packaged PostgreSQL server. This can confuse port numbers and system configuration. Evergreen 1.4 requires PostgreSQL 8.2.Installing OpenSRF 1.0.7Evergreen software is integrated with and depends on the Open Service Request Framework (OpenSRF) software system. For further information on installing, configuring and testing OpenSRF, see .Follow the steps outlined in that section and run the specified tests to ensure that OpenSRF is properly installed and configured. Do not continue with any further Evergreen installation steps until you have verified that OpenSRF has been successfully installed.Download and Unpack Evergreen Version 1.4.0.6As the opensrf user, download and extract the latest version of Evergreen. The latest version can be found here: The new directory /home/opensrf/Evergreen-ILS-1.4.0.6 will be created.Install Prerequisites to Build EvergreenIn this section you will install and configure a set of prerequisites that will be used to build Evergreen. In a following step you will actually build the software using the make utility.As the root user, enter the commands show below to build the prerequisites from the software distribution that you just downloaded and unpacked. Remember to replace [distribution] in the example with the keyword corresponding to the actual Linux distribution listed in the "Keywords" figure below.
Update the System Dynamic Library PathAs the root user, you must update the system dynamic library path to make your system recognize the newly installed libraries. Do this by creating the new file /etc/ld.so.conf.d/eg.conf containing two new library paths, then run the command ldconfig to automatically read the file and modify the system dynamic library path:Restart the PostgreSQL ServerIf PostgreSQL is running on the same system as the rest of Evergreen, as the root user you must restart the PostgreSQL server to avoid a problem where the library plperl.so cannot be found. If your PostgreSQL server is running on another system, just skip this step.Configure EvergreenAs the opensrf user, return to the Evergreen build directory and use the configure utility to prepare for the next step of compiling and linking the software:Compile, Link and Install EvergreenIn this step you will actually compile, link and install Evergreen and the default Evergreen Staff Client.As the root user, return to the Evergreen build directory and use the make utility as shown below. The Staff Client will also be automatically built, but you must remember to set the variable STAFF_CLIENT_BUILD_ID to match the version of the Staff Client you will use to connect to the Evergreen server.For further information on manually building the Staff Client, see .Copy the OpenSRF Configuration FilesAs the root user, copy the example OpenSRF configuration files into place. This replaces the configuration files that you set up in a previous step when you installed and tested OpenSRF. You should also create backup copies of the old files for troubleshooting purposes. Finally, change the ownership on the installed files to the opensrf user:Create and Configure PostgreSQL DatabaseAs the postgres user on your PostgreSQL server, create the Evergreen database.In the commands below, remember to adjust the path of the contrib repository to match your PostgreSQL server layout. For example, if you built PostgreSQL from source the path would be /usr/local/share/contrib; if you installed the PostgreSQL 8.2 server packages on Ubuntu 8.04, the path would be /usr/share/postgresql/8.2/contrib/.Create and configure the databaseAs the postgres user on the PostgreSQL system create the PostgreSQL database, then set some internal paths:Where PGSQL_VERSION is your installed PostgreSQL version (e.g. 8.2).Create new Evergreen superuserAs the postgres user on the PostgreSQL system, create the new database evergreen user and assign a password:Where MYNEWPASSWORD is the password chosen.Create Database SchemaAs the root user, create the database schema and configure your system with the corresponding database authentication details for the evergreen database user that you created in the previous step.Enter the following commands and replace HOSTNAME, PORT, PASSWORD and DATABASENAME with appropriate values.Where, on most systems, HOSTNAME will be localhost, PORT will be 5432, and PASSWORD and DATABASENAME will be those assigned when PostgreSQL was installed in the previous step.If you are entering the above command on a single line, do not include the \ (backslash) characters. If you are using the bash shell, these should only be used at the end of a line at a bash prompt to indicate that the command is continued on the next line.Evergreen installation - (continued)The remainder of the Evergreen installation procedure is identical to that for installing the latest version of Evergreen. Continue with the instructions found in.Installing OpenSRF 1.0.7 On Ubuntu or DebianThis section describes the installation of the previous version of the Open Service Request Framework (OpenSRF), a major component of the Evergreen server-side software, on Ubuntu or Debian systems. Evergreen software is integrated with and depends on the OpenSRF software system.Follow the steps outlined here and run the specified tests to ensure that OpenSRF is properly installed and configured. Do not continue with any further Evergreen installation steps until you have verified that OpenSRF has been successfully installed.The following steps have been tested on the x86 (32-bit) and x86-64 (64-bit) platforms. OpenSRF 1.0.7 has been tested on Debian Etch (4.0), Debian Lenny, Ubuntu Hardy Heron (8.04), and Ubuntu Intrepid Ibex (8.10).In the following instructions, you are asked to perform certain steps as either the root user, the opensrf user, or the postgres user.Debian -- To become the root user, issue the command su - and enter the password of the root user.Ubuntu -- To become the root user, issue the command sudo su - and enter the password of the root user.To switch from the root user to a different user, issue the command su - USERNAME. For example, to switch from the root user to the opensrf user, issue the command su - opensrf. Once you have become a non-root user, to become the root user again, simply issue the command exit".Add the OpenSRF UserAs the root user, add the opensrf user to the system. The default shell for the new user is automatically set to /bin/bash to inherit a reasonable environment:Download and Unpack Latest OpenSRF VersionAs the opensrf user, download and extract the latest version of OpenSRF. The latest version can be found here: The new directory /home/opensrf/OpenSRF-1.0.7 will be created.Install Prerequisites to Build OpenSRFIn this section you will install and configure a set of prerequisites that will be used to build OpenSRF. In a following step you will actually build the software using the make utility.As the root user, enter the commands show below to build the prerequisites from the software distribution that you just downloaded and unpacked. Remember to replace [DISTRIBUTION] in the example with the keyword corresponding to the actual Linux distribution listed in the "Keywords" figure below.
This will install a number of packages on the system that are required by OpenSRF, including some Perl modules from CPAN. You can say No to the initial CPAN configuration prompt to allow it to automatically configure itself to download and install Perl modules from CPAN. The CPAN installer will ask you a number of times whether it should install prerequisite modules - say Yes.Configure OpenSRFAs the opensrf user, return to the OpenSRF build directory and use the configure utility to prepare for the next step of compiling and linking the software. You can include the and configuration options if you wish to include support for Python and Java, respectively:Compile, Link and Install OpenSRFAs the root user, return to the OpenSRF build directory and use the make utility to compile, link and install OpenSRF:Update the System Dynamic Library PathAs the root user, you must update the system dynamic library path to make your system recognize the newly installed libraries. Do this by creating the new file /etc/ld.so.conf.d/osrf.conf containing a new library path, then run the command ldconfig to automatically read the file and modify the system dynamic library path:Define Public and Private OpenSRF DomainsDefine your public and private OpenSRF domains. For security purposes, OpenSRF uses Jabber domains to separate services into public and private realms. Throughout these instructions, we will use the example domains public.localhost for the public domain and private.localhost for the private domain. On a single-server system, the easiest way to define public and private domains is to define separate host names by adding entries to the file /etc/hosts.As the root user, edit the file /etc/hosts and add the following entries for our example domains:Change File OwnershipsAs the root user, change the ownership of files installed in the directory /openils to the opensrf user:Stop the ejabberd ServiceAs the root user, stop the ejabberd service:If ejabberd reports that it is already stopped, it may have run into a problem starting back at the installation stage. One possible fix is to kill any remaining beam and epmd processes, then edit the configuration file /etc/ejabberd/ejabberd.cfg to hardcode a domain:Edit the ejabberd configurationAs the root user, edit the file /etc/ejabberd/ejabberd.cfg and make the following changes:Change {hosts, ["localhost"]}. to {hosts, ["localhost", "private.localhost", "public.localhost"]}.Change {max_user_sessions, 10}. to {max_user_sessions, 1000}. If you see something like this instead: {access, max_user_sessions, [{10, all}]}., then change it to {access, max_user_sessions, [{1000, all}]}.Change all three occurrences of max_stanza_size to 2000000.Change both occurrences of maxrate to 500000.Comment out the line {mod_offline, []} by placing two % comment signs in front.OpenSRF installation - (continued)The remainder of the OpenSRF installation procedure is identical to that for installing the latest version of OpenSRF. Continue with the instructions found in .Installing PostgreSQLIn production Evergreen systems, the PostgreSQL database server may reside on the same system on which Evergreen is installed or on another standalone system so, by default, PostgreSQL is not automatically installed along with Evergreen. This section details the steps needed to manually install PostgreSQL on a Ubuntu or Debian system.If your PostgreSQL server will be on the same system as your Evergreen software, return to the previous section and follow those instructions. Otherwise, to manually install PostgreSQL on a system, continue with the instructions below.Some Linux distributions, such as Debian Etch (4.0), do not offer PostgreSQL version 8.2 as an installable package. Before you continue, examine the software dependencies listed in to ensure that your Linux distribution supports the required version of PostgreSQL.Install the application "stow" on your system if it is not already installed. Issue the following command as the root user:Download, compile, and install the latest release for PostgreSQL 8.2 (which was version 8.2.12 at the time of this writing). As the root user, follow these steps:Create the new user postgres to run the PostgreSQL processes. As the root user, execute this command:Initialize the database directory and start up PostgreSQL. As the root user, follow these steps:If an error occurs during the final step above, review the path of the home directory for the postgres user. It may be /var/lib/postresql instead of /home/postres.The values of several PostreSQL configuration parameters may be changed for enhanced performance. The following table lists the default values and some suggested updates for several useful parameters:
ZZZ-REVIEWADD CONTENT ON HOW TO UPDATE POSTRESQL PARAMETERSADD CONTENT ON HOW TO UPDATE POSTRESQL PARAMETERS Installing ApacheSecuring Apache (httpd)The main consideration is to secure the directory cgi-bin. The only persons that need access to this directory are Evergreen system administrators. This directory should be restricted by both IP (to those workstations designated as Evergeen Administration systems), and by username/password.ZZZ-REVIEWADD CONTENT ON HOW TO RESTRICT APACHE BY IP AND USERNAME/PASSWORD ADD CONTENT ON HOW TO RESTRICT APACHE BY IP AND USERNAME/PASSWORD A user could add new libraries, re-arrange consortia, or change user groups; or a staff member could access the directory, and change his associated security group to administrative level privileges.ZZZ-REVIEWADD MORE CONTENT FOR APACHE ADD MORE CONTENT FOR APACHE Installing the Staff ClientYou can install the Staff Client from pre-built images and packages without actually having to first build it. Pre-built packages are currently available for Windows, Mac OS X, and Linux. If you need to manually build the Staff Client, see .Installing a Pre-Built Staff ClientThis section reviews the process of installing pre-built versions of the Staff Client in various environments.Installing on WindowsA standard Windows installer that contains the current version of the Staff Client is available from the downloads section of the Evergreen website at http://www.evergreen-ils.org/downloads.php. Download the Staff Client installer, then run it. A screen that looks similar to this should appear:Click Next to continue through the guided install process. The install wizard will ask you to agree to the end-user license, ask you where to install the software, ask about where to place icons, and then will install the software on your workstation.When you run the Staff Client for the first time, a screen similar to this should appear:First, configure the server you would like to connect to in the Server section. For example, the PINES demo system is demo.gapines.org. After selecting a server, click Re-Test Server.Because this is the initial run of the Staff Client, the Workstation section in the upper-right states: Not yet configured for the specified server. The first thing that must be done to the Staff Client on every workstation is to assign it a workstation name. This is covered in .Installing on Mac OS XA Mac OS X package that contains the current version of the Staff Client is available for use with "xulrunner".Evergreen Indiana Pkg file [Evergreen v1.2.3.0]Download and install the latest version of "xulrunner" for Mac OS X. Release notes for the latest version can be found here: http://developer.mozilla.org/en/docs/XULRunner_1.8.0.4_Release_Notes. Note, later versions may not work correctly.Download and install the Mac OS X Installation package for the 1_2_3_0 Version Staff Client from http://evergreen.lib.in.us/opac/extras/files/evergreen_osx_staff_client_1_2_3.zip.To upgrade to a more recent version of the Staff Client, you can copy the directory build from a working Windows installation of the desired version of the Staff Client to your Mac. The required files may be located in a directory like this on the Windows machine: C:\Program Files\Evergreen Staff Client\build. Copy these files into the folder Resources within the Open-ILS package in your Applications directory on the Mac, overwriting files with the same names.Drag the application's icon into your toolbar for easier access.When you run the Staff Client installer, a screen will appear that looks similar to this: FIX BAD LINK: http://es.zionsville.lib.in.us/atheos/eg_osx_a.gif Click Continue, accept the license, then finish the installation. The application will be located at the destination you selected during installation. You will then be able to drag the application into your toolbar for easier access. FIX BAD LINK: http://es.zionsville.lib.in.us/atheos/eg_osx_a.gif Running directly using "xulrunner"You must install an appropriate version of "xulrunner" to match the Evergreen version. See the following table for the recommended version of "xulrunner":
Evergreen / XULRunner DependenciesEvergreen 1.6.x.xXULrunner 1.9Evergreen 1.4.x.xXULrunner 1.8.0.4 or XULrunner 1.8.0.3Evergreen 1.2.x.xXULrunner 1.8.0.4 or XULrunner 1.8.0.3
If you have issues removing previously installed "xulrunner" versions see for information on removing previous "XULRunner" versions.The Staff Client data from the directory ./staff_client/build must be placed somewhere on the machine (e.g. ~/Desktop/Evergreen_Staff_Client). Remember to call "XULRunner" with the full path to the binary, followed by the install command and the path to the client data. See the following command:This command should exit quietly. A folder will be created, named /Applications/OpenILS, containing a launcher named open_ils_staff_client.Removing previously installed "xulrunner" versionsIf you already have a newer version installed, per the release notes, you will need to remove the entire directory /Library/Frameworks/XUL.framework before downgrading.In addition, you may also need to remove the previous file /Library/Receipts/xulrunner-ver-mak.pkg.If there is no file /Library/Receipts/xulrunner-ver-mak.pkg (possibly in newer OSX releases) you need to flush the file receiptdb.If you install a newer version over a previous (older) install, the older one is not removed but the symlinks get changed to the newer one.First, get the package identifier, then purge/forget the build that was initially installed:It may not be necessary to edit the file /Library/Receipts/InstallHistory.plist after deleting the folder XUL.framework.Creating an APP file: Staff Client & "xulrunner" BundledAn APP file is basically a folder. Start with a folder structure like this:Create an APP folder structure with the following commands:Create a new file in the folder Evergreen.app/Contents/Info.plist containing the following data (adjust for your version of Evergreen):Download and install an appropriate Mac OS Xpackage of "XULRunner" from the Mozilla website (see above for recommendations).Make a copy of /Library/Frameworks/XUL.Framework inside your APP file. It should look something like this:Copy XUL.Framework/Versions/Current/xulrunner into Evergreen.app/MacOS (do not symlink; copy the file).Make Evergreen.app/Resources the root of your Evergreen application files like this:Put a Mac format icon file named Evergreen.icns in Resources.Installing on LinuxQuick Upgrade of the Staff ClientA Linux Staff Client is automatically built on the server as part of the normal make install process for Evergreen server-side software. To upgrade the Staff Client on a remote workstation with a new version, just copy the directory tree containing the Staff Client from the server to the remote workstation.The following example assumes you already have an opensrf user account on both the server and the remote workstation. Remember to replace user, client.linux.machine and eg-client-x.x.x.x with the proper user name, client machine name, and version number in the following example.As the opensrf user, change directory to the Staff Client source directory, then recursively copy the entire directory tree to the remote workstation:To test the newly copied Staff Client, as the opensrf user log into the remote workstation and execute it as shown:Building the Staff Client on the ServerA Linux Staff Client is automatically built on the server as part of the normal make install process for Evergreen server-side software.In order to install a compatible Staff Client on another Linux system, just copy the applicable files from the server to that system, or even manually build it on that system. Ensure that the BUILD_ID you choose on the server matches the BUILD_ID for each Staff Client you use on other systems.If you will be using a pre-packaged Windows version on some systems, you may want to choose the BUILD_ID on both server and other versions to match that of the Windows Staff Client. To determine which BUILD_ID is used in an existing Staff Client installation, just click About this Client on the running Staff Client.If you are allowed to make changes on the Evergreen server, another option is to create a symbolic link. In order for a copy of the Staff Client and server to work together, the BUILD_ID must match the name of the directory containing the server components of the Staff Client, or the name of a symbolic link to that directory.Building the Staff Client on the client MachineThis section is directed toward end-users who wish to use Linux rather than Windows for client machines, but have limited Linux experience. You can build the Staff Client on a Linux system without installing the Evergreen Server component. This is a relatively simple process compared to server installation, but does require some command-line work. The following directions are for building Staff Client version 1.2.1.4 on Kubuntu 7.10; you must modify them for other distributions (the instructions should work as-is for Ubuntu or Debian derivatives).PrerequisitesBoth "subversion" and "xulrunner" are required to build the Staff Client. As the root user, use "apt-get" to install packages for "subversion" and "xulrunner". You can also use "synaptic", the graphical user interface for "apt-get". For "subversion", select the latest version; for "xulrunner", select version 1.8.1.4-2ubuntu5.Download the Source CodeDetermine which version is neededFor most end-users, a specific version is required to communicate properly with the Evergreen server. Check with your system administrator, IT person, or HelpDesk to determine which Staff Client versions are supported.Next, you need to determine which tag to use when downloading the source code. Tags are markers in the source code to create a snapshot of the code as it existed at a certain time; tags usually point to tested and stable code, or at least a community-recognized release version.To determine which tag to use, browse to http://svn.open-ils.org/trac/ILS/browser. Look in the Visit drop-down box; see the list of Branches and, further down, a list of Tags. You may have to do some guesswork, but it is fairly straightforward to determine which tag to use. If the server is version 1.2.1.4, you will want to use the tag that looks most appropriate. For example, as you look through the tag list, notice the tag named 'rel_1_2_1_4'. This is the tag you need; make a note of it for the next step.Download the CodeAs the opensrf user, open a terminal (command-line prompt) and navigate to the directory in which you wish to download the Staff Client. Use the following commands to download the proper version of the source code by tag name:Remember to change rel_1_2_1_4 to the appropriate tag for your installation.Build the Staff ClientEvergreen 1.2.xIn the following example, navigate to the directory in which the source code was downloaded, then navigate to the proper subdirectory and run the make utility to actually build the Staff Client. Remember to check with your system administrator about which Staff Client BUILD_ID to use. The server checks the Staff Client BUILD_ID against itself to determine whether or not a connecting client is supported. For instance, for the PINES installation (version 1.2.1.4) the supported BUILD_ID is rel_1_2_1_4. Modify the following commands accordingly.As the opensrf user, run the following commands to build the Staff Client:Evergreen 1.4.xThe 1.4 series of Evergreen has complicated the build process for the Staff Client a bit. If you downloaded a .tar.gz (compressed tar archive) of Evergreen, then your steps will resemble the following:FIXME -- Need instructions for getting certain Javascript files from OpenSRF, preferably without actually installing OpenSRF.
If you're installing from a Subversion checkout:Run the Staff Client (from the command line)As the opensrf user, navigate to the directory build/ (not staff_client/) and run the following command:(OPTIONAL) Cleaning Up / Creating ShortcutsThe source code download included many files that are needed to build the Staff Client, but are not necessary to run it. You may wish to remove them to save space, or to create a clean directory containing the built Staff Client that can be copied to other machines. To create a clean "staging" directory in which to place the finished Staff Client, issue the following commands:Finally, test the Staff Client to verify that all the necessary files were moved to the destination directory:If there were no problems, then finish the cleanup by removing the original download directory and all subdirectories:Finally, test the copied Staff Client. You can create "Desktop / Start Menu / K-Menu" shortcuts for the Staff Client by using the following command as the target:Using "Wine" to Install On LinuxThe Linux application "Wine" is another alternative for those who wish to install the packaged Windows versions rather than building the Staff Client manually. "Wine" is a Linux application that allows users to directly run Windows executables, and is a simple way for casual Linux users to use the Staff Client. More information about "Wine" can be found at http://www.winehq.org/site/docs/wineusr-guide/getting-wine.As the root user, use "apt-get" to install the package for "Wine". You can also use "synaptic", the graphical user interface.Install "Wine"Download Windows installer for the Staff ClientAs the opensrf user, run the following commands to download the Windows installer for the proper Staff Client from the open-ils.org website and place it in a temporary directory:Run the downloaded Windows installerAs the opensrf user, navigate to the directory where you downloaded the Windows executable file, then execute it:If this step fails, you may need to configure Wine first to properly emulate WindowsXP. To do so, type the command winecfg from the command line; in the Applications tab of the window that pops up, select Default Settings and choose Windows XP from the drop-down menu, then click Apply.Launch the Staff ClientA new entry for the Staff Client should now appear somewhere in the All Applications menu of your Linux desktop. Also, find a new desktop shortcut for the Staff Client. To launch the Staff Client, visit the All Applications menu, find a section similar to WineProgram FilesEvergreen Staff ClientEvergreen Staff Client
, or else launch the Staff Client from the desktop shortcut.Running the Staff Client over an SSH TunnelThe Staff Client can use an SSH tunnel as a SOCKS 5 proxy. For more details, see .Assigning Workstation NamesThe Staff Client must be assigned to a library and given a unique name before it will connect fully to the Evergreen server. The only restriction is that the workstation's name must be unique within the assigned library. Make sure to select a workstation name that you will remember later, and reflects the role, purpose, and/or location of a particular computer. These names will come up later in statistical reporting, and can also be handy when troubleshooting.In order to assign a workstation a name, a user with appropriate permissions must login to the Staff Client. In PINES, the local system administrator (OPSM) has the ability to assign workstation names in his or her library system. Library managers (LIBM's) have the ability within their branch. To assign a workstation a name, login to the system. You will be prompted to assign the workstation a library and a name:Select the library this workstation physically operates in from the drop down menu. In this example, we have selected MGRL-MA. Type in a friendly name for the workstation. In this example, we are installing the Staff Client on the director's personal system, and have named it as such. Then hit Register.Once you have registered your workstation with the server, your screen will look like this:You are now ready to log into the Staff Client for the first time. Type in your password again, and hit Login.Manually Building the Staff ClientThis section reviews the process of manually building the Staff Client in various environments.The Staff Client is automatically built by default as part of the normal make install process for Evergreen server-side software. See to review details related to building the Staff Client in the final compile/link/install phase of the default Evergreen build process.Building the Staff ClientYou can also manually build the Staff Client by using the make utility in the Staff Client source directory (e.g., the directory /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/xul/staff_client for the current Evergreen version). There are a number of possible options to manually build special versions of the Staff Client on a Linux system. Following is a list of environment variables that can be passed to make to influence the manual build process:Option STAFF_CLIENT_BUILD_IDDuring the normal make install Evergreen server-side software build process, the variable defaults to an automatically generated date/time string, but you can also override the value of BUILD_ID.The following commands could be used during the normal build process:The following commands will manually build the Staff Client using a different BUILD_ID.As the opensrf user, change directory to the Staff Client source directory, then set the variable and build the Staff Client:Option STAFF_CLIENT_VERSIONDuring the normal make install Evergreen server-side software build process, the variable is pulled automatically from a README file in the Evergreen source root. The variable defaults to 0trunk.revision, where the value of revision is automatically generated. You can override the value of VERSION similarly to the BUILD_ID.The following commands could be used during the normal build process:The following commands will manually build the Staff Client using a different VERSION.If you plan to make extensions update automatically, the VERSION needs to conform to the format recommended in Toolkit Version Format and newer versions need to be "higher" than older versions.As the opensrf user, change directory to the Staff Client source directory, then set the variable and build the Staff Client:Option STAFF_CLIENT_STAMP_ID variableDuring the normal make install Evergreen server-side software build process, this variable is generated from STAFF_CLIENT_VERSION. You can override the value of STAMP_ID similarly to the BUILD_ID.The following commands could be used during the normal build process:The following commands will manually build the Staff Client using a different STAMP_ID.It is possible to have multiple versions of the Staff Client by specifying a different STAMP_ID for each, possibly for different uses or client-side customizations.As the opensrf user, change directory to the Staff Client source directory, then set the variable and build the Staff Client:Advanced Build OptionsIn addition to the basic options listed above, there are a number of advanced options for building the Staff Client. Most are target names for the make utility and require that you build the Staff Client from its source directory. See the following table for a list of possible make target keywords:
Keywords Targets for "make" CommandKeywordDescriptionclientsRuns "make win-client", "make linux-client", and "make generic-client" individuallyclient_dirBuilds a client directory from the build directory, without doing a rebuild. The same as "copy everything but server/".client_appPrerequisite "client_dir"; removes "install.rdf" from client directory so an APP bundle can't be installed as an extensionclient_extPrerequisite "client_dir"; remove "application.ini", "autoupdate.js", "standalone_xul_app.js" from client directory so an extension won't break FirefoxextensionPrerequisite "client_ext"; rewritten to use "client_ext"generic-clientPrerequisite "client_app"; makes an XPI file suitable for use with "xulrunner --install-app""win-xulrunnerPrerequisite "client_app"; adds Windows xulrunner to client buildlinux-xulrunnerPrerequisite "client_app"; adds Linux xulrunner to client buildwin-clientPrerequisite "win-xulrunner"; builds "setup exe" (requires that "nsis" package be installed, will add options for automatic update if configured and developer options if client build was a "make devbuild")linux-clientPrerequisite "linux_xulrunner"; builds a "tar.bz2" bundle of the Linux client[generic-|win-|linux-|extension-]updates[-client]Calls external/make_updates.sh to build full and partial updates generic/win/linux/extension prefix limit to that distribution; Adding the string "-client" builds clients and copies them to a subdirectory of the directory updates as well; the target "extension-updates-client" doesn't exist.
Descriptions of other special build options follow:Developer BuildYou can create a so-called "developer build" of the Staff Client by substituting devbuild for build when running make. The build will contain an extra configuration file that enables some developer options.As the opensrf user, run make from the Staff Client source directory:Compressed JavascriptYou can execute the Google application "Closure Compiler" to automatically review and compress Javascript code after the build process completes, by substituting compress-javascript for build when running make. For more information see Google "Closure Compiler".As the opensrf user, run the following commands from the Staff Client source directory:You can also combine Javascript review and compression, and also perform a "developer build".As the opensrf user, run the following commands from the Staff Client source directory:Automatic Update HostThe host used to check for automatic Staff Client updates can be overridden by specifying the AUTOUPDATE_HOST option. The following commands could have been used during the normal build process:You can manually set AUTOUPDATE_HOST to set up automatic update checking. The following commands will manually build the Staff Client using a different AUTOUPDATE_HOST.As the opensrf user, change directory to the Staff Client source directory, then set the variable and build the Staff Client:For more information on Automatic Updates, see .Installing and Activating a Manually Built Staff ClientThe Staff Client is automatically built, installed and activated as part of the normal make install process for Evergreen server-side software. However, if you manually build the Staff Client, then you need to take additional steps to properly install and activate it. You also have the option of installing the Staff Client on the same machine it was built on, or on a different machine.Assuming you have already built the Staff Client, and that your installation is in the directory /openils/var/web/xul, as the opensrf user, change directory to the Staff Client source directory, then execute the following commands:Packaging the Staff ClientOnce the Staff Client has been built, you can create several forms of client packages by using some targeted make commands in the Staff Client source directory.Packaging a Generic ClientThis build creates a Staff Client packaged as an XPI file to use with XULRunner. It requires that you already have the "zip" utility installed on your system. It will create the output file evergreen_staff_client.xpi, suitable for use with the XULRunner option .As the opensrf user, change directory to the Staff Client source directory, then execute the following commands:Packaging a Windows ClientThis build creates a Staff Client packaged as a Windows executable. It requires that you already have the "unzip" utility installed on your system. It also requires that you install NSIS (Nullsoft Scriptable Install System), a professional open source utility package used to create Windows installers (the "makensis" utility is installed as part of the "nsis" package). We recommend using Version 2.45 or later. This build will create the output file evergreen_staff_client_setup.exe.(OPTIONAL) If you wish for the Staff Client to have a link icon/tray icon by default, you may wish to provide a pre-modified xulrunner-stub.exe. Place it in the Staff Client source directory and "make" will automatically use it instead of the one that comes with the downloaded XULRunner release. The version of xulrunner-stub.exe need not match exactly.(OPTIONAL) You can also use a tool such as Resource Hacker to embed icons. "Resource Hacker" is an open-source utility used to view, modify, rename, add, delete and extract resources in 32bit Windows executables. See the following table for some useful icon ID strings:
Useful icon ID stringsIDI_APPICONTray icon32512Default window icon
As the opensrf user, change directory to the Staff Client source directory, then execute the following commands:Packaging a Linux ClientThis build creates a Staff Client package for Linux as a "tar.bz2" file with XULRunner already bundled with it. It creates the output file evergreen_staff_client.tar.bz2.As the opensrf user, change directory to the Staff Client source directory, then execute the following commands:Packaging a Firefox ExtensionThis build requires that you already have the "zip" utility installed on your system. It creates a Staff Client packaged as a Firefox extension and creates the output file evergreen.xpi.As the opensrf user, change directory to the Staff Client source directory, then execute the following commands:Staff Client Automatic UpdatesIt is possible to set up support for automatic Staff Client updates, either during the normal Evergreen server-side build process, or by manually building the Staff Client with certain special options.WARNINGSAutomatic update server certificate requirements are more strict than normal server requirements. Firefox and XULRunner will both ignore any automatic update server that is not validated by a trusted certificate authority. Servers with exceptions added to force the Staff Client to accept them WILL NOT WORK.In addition, automatic updates have special requirements for the file update.rdf:It must be served from an SSL server, orIt must be signed with the McCoy tool.You can pre-install the signing key into the file install.rdf directly, or install it into a copy as install.mccoy.rdf. If the latter exists it will be copied into the build instead of the original file install.rdf.Autoupdate HostThe name of the automatic update host can be provided in either of two ways:At configuration time for the normal build of the Evergreen server-side software, orDuring a manual Staff Client build process.At configuration time for the normal build of Evergreen server-side softwareThis must be done when the Evergreen server-side software is first configured (see ). As the opensrf user, use the configure utility as shown:During a manual Staff Client build processYou will used the variable AUTOUPDATE_HOST=hostname (see above). If you specify just a hostname (such as example.com) then the URL will be a secure URL (such as https://example.com. If you wish to use a non-HTTPS URL then prefix the host name with "http://" (such as http://example.com).If neither option is used then, by default, the Staff Client will not include the automatic update preferences.Building UpdatesSimilar to building clients, the targets generic-updates, win-updates, linux-updates, and extension-updates can be used individually with make to build the update files for the Staff Client. To build all the targets at once, simply use the target updates.A "full" update will be built for each specified target (or for all if you use the target updates). For all but extensions any previous "full" updates (archived by default in the directory /openils/var/updates/archives) will be used to make "partial" updates. Partial updates tend to be much smaller and will thus download more quickly, but if something goes wrong with a partial update the full update will be used as a fallback. Extensions do not currently support partial updates.As the opensrf user, change directory to the Staff Client source directory, then execute the following commands:Building updates with clientsTo save time and effort you can build updates and manual download clients at the same time by adding the string "-client" to each target name. For instance, you can specify win-updates-client. You can also specify updates-client to build all the targets at once. This does not work for extension-updates.The clients will be installed alongside the updates and listed on the web page manualupdate.html, rather than left in the Staff Client directory.As the opensrf user, change directory to the Staff Client source directory, then execute the following commands:Activating the Update ServerThis section reviews scripts associated with the update server, and requires some final adjustments to file permissions.The Apache example configuration creates a directory updates that, by default, points to the directory /openils/var/updates/pub. This directory contains one HTML file and several specially-named script files.The file updatedetails.html is the fallback web page for the update details. The "check" script is used for XULRunner updates. The "update.rdf" script is used for extension updates. The "manualupdate.html" script checks for clients to provide download links when automatic updates have failed and uses the download script to force a download of the generic client XPI (compared to Firefox trying to install it as an extension).The following scripts should be marked as executable: check, download, manualupdate.html, update.rdf. As the root user, change directory to the updates directory, then execute the following commands:Other tipsMultiple workstations on one installMultiple workstation registrations for the same server can be accomplished with a single Staff Client install by using multiple profiles. When running XULRunner you can specify the option or (uppercase "P") to force the Profile Manager to start. Unchecking the option will make this the default.Once you have opened the Profile Manager you can create additional profiles, one for each workstation you wish to register. You may need to install SSL exceptions for each profile.When building targets win-client, win-updates-client, or updates-client, you can specify NSIS_EXTRAOPTS=-DPROFILES to add an "Evergreen Staff Client Profile Manager" option to the start menu.As the opensrf user, change directory to the Staff Client source directory, then execute the following commands: Multiple Staff ClientsThis may be confusing if you are not careful, but you can log in to multiple Evergreen servers at the same time, or a single Evergreen server multiple times. In either case you will need to create an additional profile for each additional server or workstation you want to log in as (see previous tip).Once you have created the profiles, run XULRunner with the option (in addition to or if needed). Instead of XULRunner opening a new login window on your existing session it will start a new session instead, which can then be logged in to a different server or workstation ID.Running the Staff ClientRun the Staff Client on a Linux system by using the application XULRunner (installed automatically and by default with Firefox version 3.0 and later on Ubuntu and Debian distributions).For example, if the source files for the Evergreen installation are in the directory /home/opensrf/Evergreen-ILS-1.6.0.7/, start the Staff Client as shown in the following command example:Configuring a Proxy for the Staff ClientBy using an SSH proxy and an SSH tunnel, it is possible to provide secure (encrypted) network communications between the Staff Client and one or more Evergreen servers. In addition to providing excellent data security, this method also buffers and caches data traveling to and from the Staff Client and can speed up access to resources on remote Evergreen servers. This is important if your system architecture includes many Staff Clients and Evergreen servers in a busy environment, through network firewalls, or must operate over insecure networks.Why Use a Proxy for the Staff Client?There are several reasons for sending network traffic for the Staff Client through an SSH proxy:Firewalls may prevent you from reaching the server. This may happen when you are connecting the Staff Client to a test server that should not be available generally, or it may be the result of network design priorities other than ease of use.You may wish to improve security where Staff Client traffic may be susceptible to network eavesdropping. This is especially true when wireless is otherwise the best option for connecting a staff machine to the network.You may wish to buffer and cache data from remote Evergreen servers to speed up access from Staff Clients.Setting Up an SSH TunnelYou will need a server that has network access to the Evergreen server you want to reach, and allows you to log in there via SSH. Use your username and password for that SSH server to set up a tunnel.For Windows users, one good solution is the open-source utility PuTTY, a free telnet/SSH client. An example of setting up a "PuTTY" session follows:Use the menu on the left to go to ConnectionSSHTunnels.Enter 9999 in the "Source port".Choose Dynamic. Do not enter anything in the Destination text entry box.Click Add. "D9999" will now appear in the "Forwarded ports" list.Use the menu on the left to go back to "Session", and enter the host name of the SSH server.A window will open up so that you can enter your username and password. Once you are logged in, the tunnel is open.Configuring the Staff Client to Use the SSH TunnelIn order to tell the Staff Client that all traffic should be sent through the SSH tunnel just configured, you must edit the file C:\Program Files\Evergreen Staff Client\greprefs\all.js. Search this file for the word socks to find the appropriate section for the following changes.Make the following changes:Change the value of network.proxy.socks from "" to "localhost".Change the value of network.proxy.socks_port from "0" to 9999.If everything is working correctly, you should now be able to run the Staff Client and all its data will be sent encrypted through the SSH tunnel you have just configured.