From 60766396ffb87d1a5d30a2331f28f49a323b92a7 Mon Sep 17 00:00:00 2001 From: Steve Sheppard Date: Wed, 8 Sep 2010 12:40:24 -0400 Subject: [PATCH] reorder some chapters to support new chapter "Installing Staff Client" --- 1.6/admin/ServersideInstallation.xml | 883 ++++++++++++--------------- 1 file changed, 404 insertions(+), 479 deletions(-) diff --git a/1.6/admin/ServersideInstallation.xml b/1.6/admin/ServersideInstallation.xml index a271caa56a..2994a8069e 100644 --- a/1.6/admin/ServersideInstallation.xml +++ b/1.6/admin/ServersideInstallation.xml @@ -62,83 +62,6 @@ 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 section "Installing Evergreen 1.4.0.6 on Ubuntu or Debian" . The accompanying previous release of OpenSRF is version 1.0.x. Instructions for installing, configuring and testing that version are found in the section "Installing OpenSRF 1.0.x" . -
- System Hardware Requirements - This section describes various requirements of the hardware and software environment that must be fulfilled to support a successful Evergreen installation. The system requirements for running Evergreen really depend on what you want to do with it. For just evaluating the software, or for a very small library (for example, 1 circulation station, a few thousand items, and infrequent online catalog use), any modern desktop or laptop made within the last few years capable of running Linux, FreeBSD, etc. should suffice. We recommend at least 512mb of RAM. - ADD FURTHER CONTENT ON HARDWARE AND SOFTWARE REQUIREMENTS -
- Conversation on mailing-list about system requirements - - >>>From Dan Scott on [http://list.georgialibraries.org/pipermail/ - open-ils-general/2007-July/000316.html|OPEN-ILS-GENERAL]: - On 8/11/07, lan ye <lye at mail.slcl.org> wrote: - > We've been researching the Evergreen Open Source Library system, and would - > like to have a list of hardware requirements for the installation of a small - > test server. To keep things within a small budget, I would like to just use - > an ordinary PC. Could you send some information to us? - - For system requirements, it depends on how extensive you want your tests to - be. Evergreen and all of the pieces it depends on (PostgreSQL, Apache, Ejabberd) run - happily in a VMWare image allocated 512MB of RAM on my laptop with just the Project - Gutenberg e-books loaded, and that's enough to evaluate the OPAC interface / try out the - staff client / make some local changes and generally experiment. But I'm not going to - load one million bib records into that system and expect it to perform. So, probably any - hardware you have lying around would be adequate for a small test server. - - > It looks like Evergreen has been successfully installed on two Linux - > systems: Gentoo and Ubuntu. Which one is the best for us to test using - > what's already in place at other libraries? Are there any differences / - > Advantages in functionality between Gentoo and Ubuntu? - - As John said, GPLS is running on Debian, and that's the only Evergreen system that is in - production at the moment. However, the documentation for installing on Debian is a bit - scattered right now. The developers themselves used Gentoo originally, and that's what - I'm using at the moment & have documented in the wiki; the install process on Ubuntu - is very thoroughly documented and Ubuntu is reasonably close to Debian. See - http://open-ils.org/dokuwiki/doku.php?id=server_installation for the list of install - instructions for various distributions. - - As for advantages / disadvantages of particular distributions, that's a religious war - that I don't want to step into... We'll try to help you out no matter what distribution - you choose; just please choose a current release :) - - -- - Dan Scott - Laurentian University - - >>>And from James Fournie in that same [http://list.georgialibraries.org/ - pipermail/open-ils-general/2007-July/000317.html|thread]: - - We are running a test Ubuntu server on a ~1ghz Celeron PC with 512mb RAM. It seems to - be ok handling the Gutenberg samples, and our collection of about 8000 records. We did - have serious problems using anything less than 512mb RAM. Also, I tried Evergreen on a - K6 II 350, but it wasn't pretty. - - James Fournie - Digitization Librarian - Union of B.C. Indian Chiefs - -
-
-
- System Architectures - This sections describes examples of some working Evergreen system architectures, including both server-side software and Staff Client software. - A bare-minimum system requires only a single Evergreen Server and a single Evergreen Staff Client, both residing on a single server machine. In fact, that is a reasonable architecture for simple experiments or as a proof of concept in a conference-room pilot. But typical real-world systems will probably consist of at least one or two Evergreen Servers plus multiple Staff Clients. - Another simple system may require only that you install one or more instances of the Staff Client software. For instance, if your consortium already provides the Evergreen server software or if you are using the hosted version provided by Equinox, you do not need to install the Evergreen server-side software at all; you need only the Staff Client. -
- PINES - In order to provide load balancing and high-availability at the OPAC and Staff Client level, PINES has implemented a Linux Virtual Server environment with five independent mini-clusters. This allows live updates of the entire system with no perceived downtime or interruption in service. - ADD FURTHER INFORMATION ON PINES -
-
- Sitka - ADD FURTHER INFORMATION ON SITKA -
-
- Other Working Systems - ADD FURTHER INFORMATION ON OTHER WORKING SYSTEMS -
-
Installation of Server-Side Software @@ -146,7 +69,7 @@ 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 the section on "Backing Up" 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 On Ubuntu or Debian + Installing OpenSRF 1.2.x On Ubuntu or Debian This 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. @@ -529,7 +452,7 @@
- Installing Evergreen V1.6.0.7 On Ubuntu or Debian + Installing Evergreen 1.6.0.x On Ubuntu or Debian This section outlines the installation process for the latest stable version of Evergreen (1.6.0.7). 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. @@ -1214,244 +1137,295 @@ ADD EXPLANATION FOR CONFIGURING "opensrf.xml"
- -
- Post-Installation Chores -
- Remove temporary changes from Apache configuration file - As 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 the section "Modify the Apache Configuration File" 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 key - In 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 - - - The temporary SSL key was only created to expedite testing. You must get a proper SSL certificate for a public production system. - - - ADD EXPLANATION OF HOW TO GET PERMANENT SSL CERTIFICATE -
-
- Set Up Support For Reports - Evergreen reports are extremely powerful, but some configuration is required. See the section "Reports" for details. +
+ Post-Installation Chores
- Starting the Reporter Daemon - Once 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: -
- Commands to start the Reporter daemon - - $ su - opensrf - $ cd /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/src/reporter - $ ./clark-kent.pl --daemon - -
- You can also specify other options with this utility: - - --sleep=interval : number of seconds to sleep between checks for new reports to run; defaults to 10 - --lockfile=filename : where to place the lockfile for the process; defaults to /tmp/reporter-LOCK - --concurrency=integer : number of reporter daemon processes to run; defaults to "1" - --bootstrap=filename : OpenSRF bootstrap configuration file; defaults to /openils/conf/opensrf_core.xml - + Remove temporary changes from Apache configuration file + As 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 the section "Modify the Apache Configuration File" 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.
- Stopping the Reporter Daemon - To 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. - + Configure a permanent SSL key + In 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 + - 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: + The temporary SSL key was only created to expedite testing. You must get a proper SSL certificate for a public production system. - -
- Commands to stop the Reporter daemon - + + ADD EXPLANATION OF HOW TO GET PERMANENT SSL CERTIFICATE +
+
+ Set Up Support For Reports + Evergreen reports are extremely powerful, but some configuration is required. See the section "Reports" for details. + + + Starting the Reporter Daemon + Once 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: +
+ Commands to start the Reporter daemon + + $ su - opensrf + $ cd /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/src/reporter + $ ./clark-kent.pl --daemon + +
+ You can also specify other options with this utility: + + --sleep=interval : number of seconds to sleep between checks for new reports to run; defaults to 10 + --lockfile=filename : where to place the lockfile for the process; defaults to /tmp/reporter-LOCK + --concurrency=integer : number of reporter daemon processes to run; defaults to "1" + --bootstrap=filename : OpenSRF bootstrap configuration file; defaults to /openils/conf/opensrf_core.xml + + + + Stopping the Reporter Daemon + To 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: + + +
+ Commands to stop the Reporter daemon + $ su - opensrf # find and kill the process ID number(s) $ kill `ps wax | grep "Clark Kent" | grep -v grep | cut -b1-6` # remove the lock file $ rm /tmp/reporter-LOCK -
+ + +
-
- Installing the Evergreen Staff Client - The Staff Client is automatically built by default as part of the normal make install process for Evergreen server-side software. See the section "Compile, Link and Install Evergreen" to review the final compile/link/install phase of the default Evergreen build process. +
+ Installing On Other Linux Systems + ADD CONTENT FOR INSTALLING ON OTHER LINUX SYSTEMS +
+
+ Installing In Virtualized Unix Environments + Evergreen 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). + ADD CONTENT FOR INSTALLING EVERGREEN IN VIRTUALIZED UNIX ENVIRONMENTS +
+ VirtualBox + ADD CONTENT FOR VirtualBox +
+
+ VMware + ADD CONTENT FOR VMware +
+
+ VirtualPC + ADD CONTENT FOR VirtualPC +
+
+
+ Installing Previous Versions of Evergreen + Earlier 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.x. +
+ Installing Evergreen 1.4.0.6 on Ubuntu or Debian + ADD CONTENT FOR INSTALLING EVERGREEN 1.4.0.6 ON UBUNTU OR DEBIAN +
+
+ Installing OpenSRF 1.0.x + ADD CONTENT FOR INSTALLING OPENSRF 1.0.x +
+
+
+ Installing PostgreSQL + ADD CONTENT FOR POSTGRESQL +
+
+ Installing Apache
- Building the Evergreen Staff Client - You can also build the Staff Client manually by running the make command in the source directory /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/xul/staff_client. The make command accepts a number of options to build special versions of the Staff Client. Following is a list of environment variables that can be passed to make to influence the manual build process: -
- Option STAFF_CLIENT_BUILD_ID - This variable defaults to an automatically generated date/time string during the normal Evergreen server-side software installation process, but you can also specify it manually. The following commands could have been used during the normal build process: -
- Commands for normal Evergreen build - + Securing 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. + 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. +
+ ADD MORE CONTENT FOR APACHE +
+
+
+ Installation of the Staff Client + The Staff Client is automatically built by default as part of the normal make install process for Evergreen server-side software. See the section "Compile, Link and Install Evergreen" to review the final compile/link/install phase of the default Evergreen build process. +
+ Building the Evergreen Staff Client + You can also build the Staff Client manually by running the make command in the source directory /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/xul/staff_client. The make command accepts a number of options to build special versions of the Staff Client. Following is a list of environment variables that can be passed to make to influence the manual build process: +
+ Option STAFF_CLIENT_BUILD_ID + This variable defaults to an automatically generated date/time string during the normal Evergreen server-side software installation process, but you can also specify it manually. The following commands could have been used during the normal build process: +
+ Commands for normal Evergreen build + $ su - root $ cd /home/opensrf/Evergreen-ILS-1.6.0.7 $ make STAFF_CLIENT_BUILD_ID=rel_1_6_0_7 install ... -
- You can also manually set the BUILD_ID. 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: -
- Commands to manually build the Staff Client - +
+ You can also manually set the BUILD_ID. 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: +
+ Commands to manually build the Staff Client + $ su - opensrf $ cd /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/xul/staff_client $ make STAFF_CLIENT_BUILD_ID=my_test_id build ... -
-
-
- Option STAFF_CLIENT_VERSION - During the normal Evergreen server-side software build process this variable is pulled automatically from a README file in the Evergreen source root, but you can also specify it manually. The following commands could have been used during the normal build process: -
- Commands used for normal Evergreen build - +
+
+
+ Option STAFF_CLIENT_VERSION + During the normal Evergreen server-side software build process this variable is pulled automatically from a README file in the Evergreen source root, but you can also specify it manually. The following commands could have been used during the normal build process: +
+ Commands used for normal Evergreen build + $ su - root $ cd /home/opensrf/Evergreen-ILS-1.6.0.7 $ make STAFF_CLIENT_VERSION=0mytest.200 install ... -
- If you manually build the Staff Client, VERSION will default to 0trunk.revision, where revision is either automatically pulled from SVN or an empty string on failure. If you wish to make extensions update automatically then your version needs to conform to the format found in Toolkit Version Format and newer versions need to be "higher" than older versions. - You can manually set VERSION. The following commands will manually build the Staff Client using a different VERSION. - As the opensrf user, change directory to the Staff Client source directory, then set the variable and build the Staff Client: -
- Commands to manually build the Staff Client - +
+ If you manually build the Staff Client, VERSION will default to 0trunk.revision, where revision is either automatically pulled from SVN or an empty string on failure. If you wish to make extensions update automatically then your version needs to conform to the format found in Toolkit Version Format and newer versions need to be "higher" than older versions. + You can manually set VERSION. The following commands will manually build the Staff Client using a different VERSION. + As the opensrf user, change directory to the Staff Client source directory, then set the variable and build the Staff Client: +
+ Commands to manually build the Staff Client + $ su - opensrf $ cd /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/xul/staff_client $ make STAFF_CLIENT_VERSION=0mytest.200 build ... -
-
-
- Option STAFF_CLIENT_STAMP_ID variable - During the normal Evergreen server-side software build process this variable is generated from STAFF_CLIENT_VERSION, but you can also specify it manually. The following commands could have been used during the normal build process: -
- Commands used for normal Evergreen build - +
+
+
+ Option STAFF_CLIENT_STAMP_ID variable + During the normal Evergreen server-side software build process this variable is generated from STAFF_CLIENT_VERSION, but you can also specify it manually. The following commands could have been used during the normal build process: +
+ Commands used for normal Evergreen build + $ su - root $ cd /home/opensrf/Evergreen-ILS-1.6.0.7 $ make STAFF_CLIENT_STAMP_ID=my_test_stamp install ... -
- It is possible to have multiple versions of the Staff Client with different stamps, possibly for different uses or client-side customizations. - You can manually set STAMP_ID. The following commands will manually build the Staff Client using a different STAMP_ID. - As the opensrf user, change directory to the Staff Client source directory, then set the variable and build the Staff Client: -
- Commands to manually build the Staff Client - +
+ It is possible to have multiple versions of the Staff Client with different stamps, possibly for different uses or client-side customizations. + You can manually set STAMP_ID. The following commands will manually build the Staff Client using a different STAMP_ID. + As the opensrf user, change directory to the Staff Client source directory, then set the variable and build the Staff Client: +
+ Commands to manually build the Staff Client + $ su - opensrf $ cd /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/xul/staff_client $ make STAFF_CLIENT_STAMP_ID=my_test_stamp build ... -
-
+
-
- Advanced Build Options - In addition to the basic options listed above, there are a number of other 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" Command - - - - - - Keyword - Description - - - - - clients - Run "make win-client", "make linux-client", and "make generic-client" individually - - - client_dir - Build a client directory from the build directory, without doing a rebuild. The same as "copy everything but server/". - - - client_app - Prereq "client_dir"; removes "install.rdf" from client directory so an app bundle can't be installed as an extension - - - client_ext - Prereq "client_dir"; remove "application.ini", "autoupdate.js", "standalone_xul_app.js" from client directory so an extension won't break Firefox - - - extension - Prereq "client_ext"; rewritten to use "client_ext" - - - generic-client - Prereq "client_app"; make an XPI file suitable for use with "xulrunner --install-app"" - - - win-xulrunner - Prereq "client_app"; add Windows xulrunner to client build - - - linux-xulrunner - Prereq "client_app"; add Linux xulrunner to client build - - - win-client - Prereq "win-xulrunner"; build "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-client - Prereq "linux_xulrunner"; build a "tar.bz2" bundle of the Linux client - - - [generic | win | linux | extension]-updates[-client] - Call external/make_updates.sh to build full and partial updates generic/win/linux/extension prefix limit to that distribution; Adding "-client" builds clients and copies them to a subdirectory of the "updates" directory as well; "extension-updates-client" doesn't exist. - - - -
- - - Developer Build - You 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 special developer options. - As the opensrf user, run make from the Staff Client source directory: -
- Commands to do a "developer build" - +
+
+ Advanced Build Options + In addition to the basic options listed above, there are a number of other 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" Command + + + + + + Keyword + Description + + + + + clients + Run "make win-client", "make linux-client", and "make generic-client" individually + + + client_dir + Build a client directory from the build directory, without doing a rebuild. The same as "copy everything but server/". + + + client_app + Prereq "client_dir"; removes "install.rdf" from client directory so an app bundle can't be installed as an extension + + + client_ext + Prereq "client_dir"; remove "application.ini", "autoupdate.js", "standalone_xul_app.js" from client directory so an extension won't break Firefox + + + extension + Prereq "client_ext"; rewritten to use "client_ext" + + + generic-client + Prereq "client_app"; make an XPI file suitable for use with "xulrunner --install-app"" + + + win-xulrunner + Prereq "client_app"; add Windows xulrunner to client build + + + linux-xulrunner + Prereq "client_app"; add Linux xulrunner to client build + + + win-client + Prereq "win-xulrunner"; build "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-client + Prereq "linux_xulrunner"; build a "tar.bz2" bundle of the Linux client + + + [generic | win | linux | extension]-updates[-client] + Call external/make_updates.sh to build full and partial updates generic/win/linux/extension prefix limit to that distribution; Adding "-client" builds clients and copies them to a subdirectory of the "updates" directory as well; "extension-updates-client" doesn't exist. + + + +
+ + + Developer Build + You 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 special developer options. + As the opensrf user, run make from the Staff Client source directory: +
+ Commands to do a "developer build" + $ su - opensrf $ cd /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/xul/staff_client $ make devbuild ... -
- - - Compressed Javascript - You can automatically run the Google "Closure Compiler" utility to review and compress Javascript code after the build process completes by substituting "compress-javascript" for "build" when running make. - As the opensrf user, run the following commands from the Staff Client source directory: -
- Commands to compress Javascript - +
+ + + Compressed Javascript + You can automatically run the Google "Closure Compiler" utility to review and compress Javascript code after the build process completes by substituting "compress-javascript" for "build" when running make. + As the opensrf user, run the following commands from the Staff Client source directory: +
+ Commands to compress Javascript + $ su - opensrf $ cd /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/xul/staff_client $ make compress-javascript ... -
- 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: -
- Commands to compress Javascript and do a "developer build" - +
+ 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: +
+ Commands to compress Javascript and do a "developer build" + $ su - opensrf $ cd /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/xul/staff_client @@ -1459,168 +1433,168 @@ $ make devbuild compress-javascript ... -
- - - Automatic Update Host - The 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: -
- Commands to set AUTOUPDATE_HOST for normal Evergreen build - +
+ + + Automatic Update Host + The 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: +
+ Commands to set AUTOUPDATE_HOST for normal Evergreen build + $ su - root $ cd /home/opensrf/Evergreen-ILS-1.6.0.7 $ make AUTOUPDATE_HOST=localhost install ... -
- You can manually set AUTOUPDATE_HOST. 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: -
- Commands to manually specify AUTOUPDATE_HOST - +
+ You can manually set AUTOUPDATE_HOST. 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: +
+ Commands to manually specify AUTOUPDATE_HOST + $ su - opensrf $ cd /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/xul/staff_client $ make AUTOUPDATE_HOST=localhost build ... -
- For more information see the section "Automatic Updates". - - -
-
- Installing and Activating the Staff Client - The 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 from its source directory, then you need to take additional steps to install and active it. - 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: -
- Commands to install and active the Staff Client - +
+ For more information see the section "Automatic Updates". + + +
+
+ Installing and Activating the Staff Client + The 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 from its source directory, then you need to take additional steps to install and active it. + 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: +
+ Commands to install and active the Staff Client + $ su - opensrf $ cd /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/xul/staff_client $ mkdir -p "/openils/var/web/xul/$(cat build/STAMP_ID)" $ cp -R build/server "/openils/var/web/xul/$(cat build/STAMP_ID)" -
-
-
- Packaging the Staff Client - Once the Staff Client has been built, you can create several forms of client packages by using some targetted make commands in the Staff Client source directory. - - - Packaging a Generic Client - This build creates a Staff Client packaged as an XPI file suitable for use with XULRunner. - This special build 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 parameter --install-app. - As the opensrf user, change directory to the Staff Client source directory, then execute the following commands: -
- Commands to package a "generic" client - +
+
+
+ Packaging the Staff Client + Once the Staff Client has been built, you can create several forms of client packages by using some targetted make commands in the Staff Client source directory. + + + Packaging a Generic Client + This build creates a Staff Client packaged as an XPI file suitable for use with XULRunner. + This special build 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 parameter --install-app. + As the opensrf user, change directory to the Staff Client source directory, then execute the following commands: +
+ Commands to package a "generic" client + $ su - opensrf $ cd /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/xul/staff_client $ make generic-client ... -
- - - Packaging a Windows Client - This build creates a Staff Client packaged as a Windows executable - This special build requires that you already have the "zip" 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. The output file "evergreen_staff_client_setup.exe" will be created. - (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. - 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 - As the opensrf user, change directory to the Staff Client source directory, then execute the following commands: -
- Useful icon ID strings - +
+ + + Packaging a Windows Client + This build creates a Staff Client packaged as a Windows executable + This special build requires that you already have the "zip" 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. The output file "evergreen_staff_client_setup.exe" will be created. + (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. + 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 + As the opensrf user, change directory to the Staff Client source directory, then execute the following commands: +
+ Useful icon ID strings + IDI_APPICON - Tray icon 32512 - Default window icon -
- -
- Commands to build a Windows client - +
+ +
+ Commands to build a Windows client + $ su - opensrf $ cd /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/xul/staff_client $ make win-client ... -
- - - Packaging a Linux Client - This build creates a Staff Client package for Linux as a "tar.bz2" file with XULRunner already bundled with it. The output file "evergreen_staff_client.tar.bz2" will be created. - As the opensrf user, change directory to the Staff Client source directory, then execute the following commands: -
- Commands to build a Linux client - +
+ + + Packaging a Linux Client + This build creates a Staff Client package for Linux as a "tar.bz2" file with XULRunner already bundled with it. The output file "evergreen_staff_client.tar.bz2" will be created. + As the opensrf user, change directory to the Staff Client source directory, then execute the following commands: +
+ Commands to build a Linux client + $ su - opensrf $ cd /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/xul/staff_client $ make linux-client ... -
- - - Packaging a Firefox Extension - This special build requires that you already have the "zip" utility installed on your system. This build creates a Staff Client packaged as a Firefox extension. The output file "evergreen.xpi" will be created. - As the opensrf user, change directory to the Staff Client source directory, then execute the following commands: -
- Commands to build a Firefox extension - +
+ + + Packaging a Firefox Extension + This special build requires that you already have the "zip" utility installed on your system. This build creates a Staff Client packaged as a Firefox extension. The output file "evergreen.xpi" will be created. + As the opensrf user, change directory to the Staff Client source directory, then execute the following commands: +
+ Commands to build a Firefox extension + $ su - opensrf $ cd /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/xul/staff_client $ make extension ... -
- - -
-
- Automatic Updates - It is possible to set up support for automatic Staff Client updates, either during the normal Evergreen server-side build process, or by later building the Staff Client with certain special options. - Automatic 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, or - It must be signed with the utility McCoy. - - 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. - The name of the automatic update host can be provided in either of two ways: - - At configuration time for the Evergreen server-side software, or - During the Staff Client build process - + + + +
+
+ Automatic Updates + It is possible to set up support for automatic Staff Client updates, either during the normal Evergreen server-side build process, or by later building the Staff Client with certain special options. + Automatic 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, or + It must be signed with the utility McCoy. + + 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. + The name of the automatic update host can be provided in either of two ways: + + At configuration time for the Evergreen server-side software, or + During the Staff Client build process + +
+ Specifying the Automatic Update Host
- Specifying the Automatic Update Host -
- At configuration time for the Evergreen server-side software - This must be done when the Evergreen server-side software is first configured (see the section "Configure Evergreen" ). As the opensrf user, use the utility "configure" as shown: -
- Commands to configure Evergreen - + At configuration time for the Evergreen server-side software + This must be done when the Evergreen server-side software is first configured (see the section "Configure Evergreen" ). As the opensrf user, use the utility "configure" as shown: +
+ Commands to configure Evergreen + $ su - opensrf $ cd /home/opensrf/Evergreen-ILS-1.6.0.7 $ ./configure --prefix=/openils --sysconfdir=/openils/conf --with-updateshost=hostname $ make ... -
-
-
- During the Staff Client build process - You 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 HTTPS URL (such as "https://example.com"). If you wish to use a non-HTTPS URL then prefix the hostname 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 Updates - Similar 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 the target "updates" is used). 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: -
- Commands for building updates - + During the Staff Client build process + You 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 HTTPS URL (such as "https://example.com"). If you wish to use a non-HTTPS URL then prefix the hostname 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 Updates + Similar 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 the target "updates" is used). 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: +
+ Commands for building updates + $ su - opensrf $ cd /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/xul/staff_client @@ -1638,16 +1612,16 @@ $ make extension-updates ... -
-
-
- Building updates with "-client" - To 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 "manualupdate.html" page, 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: -
- Commands for building updates - +
+
+
+ Building updates with "-client" + To 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 "manualupdate.html" page, 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: +
+ Commands for building updates + $ su - opensrf $ cd /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/xul/staff_client @@ -1663,113 +1637,64 @@ $ make linux-updates-client ... -
-
-
- Activating the Update Server - This section reviews scripts associated with the update server, and requires some final adjustments to file permissions. - The Apache example configuration creates an "updates" directory that, by default, points to the directory /openils/var/updates/pub. This directory contains one HTML file and several specially-named script files - The "updatedetails.html" file 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). - As the root user, change directory to the updates directory, then execute the following commands: - The following scripts should be marked as executable: check, download, manualupdate.html, update.rdf. -
- Changing permissions of scripts - +
+
+
+ Activating the Update Server + This section reviews scripts associated with the update server, and requires some final adjustments to file permissions. + The Apache example configuration creates an "updates" directory that, by default, points to the directory /openils/var/updates/pub. This directory contains one HTML file and several specially-named script files + The "updatedetails.html" file 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). + As the root user, change directory to the updates directory, then execute the following commands: + The following scripts should be marked as executable: check, download, manualupdate.html, update.rdf. +
+ Changing permissions of scripts + $ su - root $ cd /openils/var/updates/pub $ chmod +x check download manualupdate.html update.rdf -
-
+
-
- Other tips - - - Multiple workstations on one install - Multiple 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 "-profilemanager" or "-P" (uppercase "P") to force the Profile Manager to start. Unchecking the "Don't ask at startup" 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: -
- Command to add start menu option - +
+
+ Other tips + + + Multiple workstations on one install + Multiple 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 "-profilemanager" or "-P" (uppercase "P") to force the Profile Manager to start. Unchecking the "Don't ask at startup" 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: +
+ Command to add start menu option + $ su - opensrf $ cd /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/xul/staff_client $ make NSIS_EXTRAOPTS=-DPROFILES win-client ... -
- - - Multiple Staff Clients - This 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 done so, run XULRunner with the option "-no-remote" (in addition to "-profilemanger" or "-P" if neeeded). 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 Evergreen Staff Client - ADD CONTENT: LINUX VS WINDOWS STAFF CLIENT - Run the Evergreen 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: -
- Commands to run the Staff Client - +
+ + + Multiple Staff Clients + This 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 done so, run XULRunner with the option "-no-remote" (in addition to "-profilemanger" or "-P" if neeeded). 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 Evergreen Staff Client + ADD CONTENT: LINUX VS WINDOWS STAFF CLIENT + Run the Evergreen 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: +
+ Commands to run the Staff Client + $ su - opensrf $ xulrunner /home/opensrf/Evergreen-ILS-1.6.0.7/Open-ILS/xul/staff_client/build/application.ini -
-
-
-
-
- Installing Evergreen On Other Linux Systems - ADD CONTENT FOR INSTALLING ON OTHER LINUX SYSTEMS -
-
- Installing Evergreen in Virtualized Unix Environments - Evergreen 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). - ADD CONTENT FOR INSTALLING EVERGREEN IN VIRTUALIZED UNIX ENVIRONMENTS -
- VirtualBox - ADD CONTENT FOR VirtualBox -
-
- VMware - ADD CONTENT FOR VMware -
-
- VirtualPC - ADD CONTENT FOR VirtualPC -
-
-
- Installing Previous Versions of Evergreen - Earlier 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.x. -
- Installing Evergreen 1.4.0.6 on Ubuntu or Debian - ADD CONTENT FOR INSTALLING EVERGREEN 1.4.0.6 ON UBUNTU OR DEBIAN -
-
- Installing OpenSRF 1.0.x - ADD CONTENT FOR INSTALLING OPENSRF 1.0.x -
-
-
- Installing PostgreSQL - ADD CONTENT FOR POSTGRESQL -
-
- Apache -
- Securing 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. - 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. +
- ADD MORE CONTENT FOR APACHE
memcached Servers -- 2.43.2