Evergreen Install Day Notes 2008 January 30
On Monday, January 28, 2007 four people got together to attempt to install Evergreen on a Dell PowerEdge 2900 running Debian Etch (4.0) on a server at TCNJ. Besides myself, also attending was Kurt Wagner (William Patterson), Dave Hoover (Rutgers/VALE), and Kate Lynch (Drexel). We started at about 9:00 AM and we ended at about 5:00 PM. Except for lunch, we pretty much worked straight through. While we didn’t end up with a working system at the end of the day, we all learned a little more about the architecture of Evergreen and the underlying software. Basically, the place where we quit was with the config.cgi working where we can create and add basic systems configuration settings such as item types a but the OPAC and the staff clients were not working. (Note: I have since gotten Evergreen working with only a little bit more work, continue reading)
The reason behind our problems was the underlying database was not created completely. When install Evergreen, there database gets created. apparently, by a shell script (builddb.sh) that executes a series of SQL statements on the underlying PostgreSQL database. This script is called elsewhere in the install process. This apparently failed without any notice (at least not that we noticed). The reason for the failure, at least initially may have been because the Debian server we had set up had two versions of Postgres installed (7.4,and 8.1), and that was confusing things. However, even after fixing that problem, we still did not get the scripts to run correctly. After locatign the builddb.sh script and running it by hand, we found out that we were missing a programming language in the PostgreSQL database. Entering the following command seemed to fix that particular problem:
su -c "createlang plpgsql evergreen" - postgres
At this point the whole script was still wasn’t working, and it was time to go home. At that point, the staff client was timing out and not connecting, the OPAC was given “Internal Server Configuration Errors” and basically things just were not all that well.
I looked at it again today, and I figured how to get the SQL script to run. The script was actually fine, but I was using a wrong option trying to run it on the command line (You had to put your database version as a command line argument. I used “8.1″ but I should have been using 81). Once I fixed that, things went a little more smoothly, and the OPAC was up and working (with no data, however). The staff client, however was still not functioning. I was able to login, but at that point I get an error saying “TypeError: Branch has no properties” and pretty much nothing happens. Thanks to the kind folks on the Evergreen IRC channel, that was solved by re-running the autogen.sh program. After doing that, I was able to login, use Z39.50 to locate a record, and add it to the database. After adding an item record, I was also able to search and find it. So, I think I have a functioning Evergreen install.
Besides the SQL problems, we had a few other problems with the install, that we were able to figure out how to deal with. The install documentation needs a little editing as a few things were missing (things like, download the software) or could have been expanded upon. I took some notes, so maybe I can help improve it a little. Most of our problems related to not having experience with PostgreSQL and Jabber. Besides the issue with two versions of Postgres being installed, we also had to change the port for 8.1 since it was running on a different port then expected. We also had some issues knowing what server name to use where (localhost, evergreen, the FQDN?). We muddled through it though and really it was a good learning experience. We may have had less issues if we tried the Debian Evergreen install script that John Schmidt created, but we decided to do it the other way so we can learn a little more about the architecture (which we did).
Still to do at this point is to get the proper static IP information configured, and start figuring out how to load data. Also, I need to get the network people to open the proper firewall ports so others can connect from off campus