RE: [OPEN-ILS-DEV] ejabberd problems
Hi all,
Interesting discussions on this list - I think I'll stay subscribed
(even though I've now fixed my problem read on.)
In a moment of impatience, I followed RobertC's advice to simply
rebuild the system:
When you installed Deiban did you do a generic webserver
install or did you also install Jabber and Postgresql? If I remember
correctly, I just did a webserver install and no additional packages
then followed the instructions at:
http://www.open-ils.org/dokuwiki/doku.php?id=installing_evergreen_1.2_
on_debian_etch_x86_32-bit
the automated script takes care of the rest of the packages
needed.
You can verify that Apache is working correctly before
proceeding with the Evergreen install.
RobertC
So I used my lunch break to do another rebuild of the system. The only
difference between the two builds IIRC was that I didn't install a
database server the second time around, which I had the first time. It
seems that if I had simply used dpkg to get rid of PostgreSQL 7.4, I
may have had fewer problems; I remember noticing that there were some
7.4 directories kicking around the place even after I had used apt-get
to remove it.
Anyway, after going through the install for OpenSRF and Open-ILS,
starting the webserver initially threw a couple of errors:
[EMAIL PROTECTED]:/etc/apache2/ssl# /etc/init.d/apache2 restart
Forcing reload of web server (apache2)... waiting Syntax error
on line 69 of /etc/apache2/sites-enabled/eg.conf:
Invalid command 'CacheRoot', perhaps misspelled or defined by
a module not included in the server configuration
failed!
Fortunately, this is easily enough solved by enabled mod_cache and
mod_disk_cache:
[EMAIL PROTECTED]:/etc/apache2/ssl# ln -s
/etc/apache2/mods-available/cache.load
/etc/apache2/mods-enabled/cache.load
[EMAIL PROTECTED]:/etc/apache2/ssl# ln -s
/etc/apache2/mods-available/disk_cache.load
/etc/apache2/mods-enabled/disk_cache.load
[EMAIL PROTECTED]:/etc/apache2/ssl# /etc/init.d/apache2 start
Starting web server (apache2)
[EMAIL PROTECTED]:/etc/apache2/ssl#
And that gives some joy. I couldn't believe that it was working until
I actually loaded up http://evergreen/, but sure enough, it is.
Thanks for all of your suggestions, folks - sorry I didn't man up to a
real solution rather than just skirting the problem. Maybe next
time...
Cyrus
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Dan Scott
Sent: 14 July 2008 14:18
To: Evergreen Development Discussion List
Subject: Re: [OPEN-ILS-DEV] ejabberd problems
Hi Cyrus:
2008/7/14 Lyons, Cyrus 2 [EMAIL PROTECTED]:
Dear all,
Apologies in advance if this has already been looked at, but
extensive
searching hasn't yielded many results.
I'm having a number of issues after an automated install on Debian
Etch. This is actually my second install on this machine: The first
had similar problems which I assumed were due to numerous hostname
changes throughout it's life, and I figured it would be quicker to
just build the computer cleanly to get rid of any old config files
and
start from scratch than to weed out the problem. Bad call,
unfortunately - having identical problems now, so perhaps a waste of
time...
Perhaps. You said you did an automated install - was it using John
Schmidt's script? This might help us narrow down the problem. What
version of Evergreen?
In the Debian Etch install instructions, I think I'll insert a If you
run into problems with the login via srfsh step, stop now. Run
Open-ILS/src/support-scripts/settings-tester.pl; if that doesn't
provide any helpful feedback, post your problem to the open-ils-dev
mailing list before making any drastic changes to your system
configuration. You're probably closer to a solution than you think.
(something along the lines of the advice to sit still rather than keep
wandering in a forest when you're lost).
The issues are as follows.
First, after the install, running the admin login command failed:
[EMAIL PROTECTED]:~# /openils/bin/srfsh
srfsh# login admin open-ils
???: login admin open-ils
srfsh# exit
I had seen various error messages thrown during the install script
itself, but unfortunately flashing past too quickly to really take
notes.
~/srfsh.log yielded some information:
[/*--S
osrfMessage--*/{threadTrace:0,type:CONNECT}/*--E
osrfMessage--*/]
srfsh 2008-07-14 07:42:44 [DEBG:9022:osrf_stack.c:73:] We
received 1 messages from [EMAIL PROTECTED]/open-ils.auth
srfsh 2008-07-14 07:42:44 [WARN:9022:osrf_stack.c:84:] !!!
Received Jabber layer error message
srfsh 2008-07-14 07:42:44 [WARN:9022:osrf_stack.c:94:] *
Jabber Error is for top level remote id
[EMAIL PROTECTED]/open-ils.auth], no one to send my
message
too!!!
srfsh 2008-07-14 07:42:44 [INFO:9022:osrf_stack.c:103:]
Message processing duration 0.65
Re: [OPEN-ILS-DEV] Rewrite of build-db.sh
2008/7/15 Aaron Joyner [EMAIL PROTECTED]: The attached patch is a rewrite of build-db.sh. I originally intended to just make it gracefully handle missing files, but I got on a roll. A break down of changes, by bullet points: - validate that the fts-config.sql script exists for the specified database version - if it does not, detect the latest available version, warn the user, suggest aborting, offer to continue w/ the latest available version - rework call of psql to avoid PGPASSWORD on the command line, visible via ps - warn user if psql fails attempting to import any of these files for reasons such as couldn't connect, or file not found (not sql script errors) - provide commented out option to fail on sql script errors, for future convenience when the scripts run cleanly w/o errors - limit line length to 80 characters (a nearly unbreakable habit from work) There aren't a large number of shell scripts in the depot, the only thing which had a sufficiently large amount of style to go by was Open-ILS/examples/oils_ctl.sh. I adopted that commenting and indenting style, if that's not an appropriate example, please provide suggestions or pointers to a style guide. oils_ctl.sh is a bash script, but build-db.sh originally defined #!/bin/sh, so I opted to avoid the few bash style elements from oils_ctl.sh that caught my eye (function foo()..., for example), and leave it as a /bin/sh script, figuring it's better for compatibility. I've endeavoured to follow the submitting doc as closely as possible (http://open-ils.org/documentation/contributing.html#Submitting%20a%20Patch), but if I'm missed anything, or you require any additional information, just let me know. Thanks for the interesting project! I look forward to contributing more code in the future. Aaron S. Joyner Hah! This is really great, Aaron - I've thought about overhauling build-db.sh a few times but never given it a go. Sadly, we may have a bit of a collision in one small area, as I committed an initial PostgreSQL 8.3 full text search schema to trunk about 8 hours ago - so if a user doesn't specify a PostgreSQL version for your script, they'll get 8.3 (and probably suffer ignominous failure). The approach I had been thinking about was using the database credentials to do an initial login to the database to grab the server version (SHOW server_version or SHOW server_version_num, whichever is easier to parse) and use that to take the decision out of the user's hands. Or at least provide a sanity check. Would you be interested in taking a crack at refining your patch in this fashion? Thanks a ton, Aaron (even if you decide not to tackle that)! -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] ejabberd problems
On Tuesday 15 July 2008 4:15 Lyons, Cyrus 2 wrote: [snip] Anyway, after going through the install for OpenSRF and Open-ILS, starting the webserver initially threw a couple of errors: [EMAIL PROTECTED]:/etc/apache2/ssl# /etc/init.d/apache2 restart Forcing reload of web server (apache2)... waiting Syntax error on line 69 of /etc/apache2/sites-enabled/eg.conf: Invalid command 'CacheRoot', perhaps misspelled or defined by a module not included in the server configuration failed! Fortunately, this is easily enough solved by enabled mod_cache and mod_disk_cache: [EMAIL PROTECTED]:/etc/apache2/ssl# ln -s /etc/apache2/mods-available/cache.load /etc/apache2/mods-enabled/cache.load [EMAIL PROTECTED]:/etc/apache2/ssl# ln -s /etc/apache2/mods-available/disk_cache.load /etc/apache2/mods-enabled/disk_cache.load [EMAIL PROTECTED]:/etc/apache2/ssl# /etc/init.d/apache2 start Starting web server (apache2) [EMAIL PROTECTED]:/etc/apache2/ssl# Hi Cyrus, mod_cache is no longer needed as of Evergreen 1.2.2.2. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] Problem With VMware Image
Okay since the new version was released this morning ill wait and try the new version out. - Original Message - From: Dan Scott [EMAIL PROTECTED] To: Evergreen Development Discussion List open-ils-dev@list.georgialibraries.org Sent: Monday, July 14, 2008 3:44 PM Subject: Re: [OPEN-ILS-DEV] Problem With VMware Image Augh. Change the password in /openils/conf/live-db-setup.pl from openils to evergreen and run /etc/init.d/apache2 force-reload. That should fix you up. I'll fix this when 1.2.2.3 comes out (any day now!). Sorry for the frustration. Dan 2008/7/14 Ryan Laverdiere [EMAIL PROTECTED]: Hi all, It seems when i go to the bootstraping scripts and go to any of the links I get an internal server error! -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Rewrite of build-db.sh
On Tue, Jul 15, 2008 at 9:05 AM, Dan Scott [EMAIL PROTECTED] wrote: 2008/7/15 Aaron Joyner [EMAIL PROTECTED]: The attached patch is a rewrite of build-db.sh. I originally intended to just make it gracefully handle missing files, but I got on a roll. A break down of changes, by bullet points: - validate that the fts-config.sql script exists for the specified database version - if it does not, detect the latest available version, warn the user, suggest aborting, offer to continue w/ the latest available version - rework call of psql to avoid PGPASSWORD on the command line, visible via ps - warn user if psql fails attempting to import any of these files for reasons such as couldn't connect, or file not found (not sql script errors) - provide commented out option to fail on sql script errors, for future convenience when the scripts run cleanly w/o errors - limit line length to 80 characters (a nearly unbreakable habit from work) There aren't a large number of shell scripts in the depot, the only thing which had a sufficiently large amount of style to go by was Open-ILS/examples/oils_ctl.sh. I adopted that commenting and indenting style, if that's not an appropriate example, please provide suggestions or pointers to a style guide. oils_ctl.sh is a bash script, but build-db.sh originally defined #!/bin/sh, so I opted to avoid the few bash style elements from oils_ctl.sh that caught my eye (function foo()..., for example), and leave it as a /bin/sh script, figuring it's better for compatibility. I've endeavoured to follow the submitting doc as closely as possible (http://open-ils.org/documentation/contributing.html#Submitting%20a%20Patch), but if I'm missed anything, or you require any additional information, just let me know. Thanks for the interesting project! I look forward to contributing more code in the future. Aaron S. Joyner Hah! This is really great, Aaron - I've thought about overhauling build-db.sh a few times but never given it a go. Sadly, we may have a bit of a collision in one small area, as I committed an initial PostgreSQL 8.3 full text search schema to trunk about 8 hours ago - so if a user doesn't specify a PostgreSQL version for your script, they'll get 8.3 (and probably suffer ignominous failure). Yeah, I saw the patch go in and thought briefly about it. In general, the detection code currently isn't intended to come into play unless there *isn't* a version in place. So, it won't adversely affect 8.2 users at present, assuming they properly specify a database version, but if there are no major changes in version 8.4, you won't need to check in a file in the same way that 8.1 and 8.2 had their own duplicated version of the file. On the other hand... that's not too future proof, it's really just intended to help as a best guess to use the last version if one doesn't exist. Note that it's also currently coupled with really big warnings. :) The approach I had been thinking about was using the database credentials to do an initial login to the database to grab the server version (SHOW server_version or SHOW server_version_num, whichever is easier to parse) and use that to take the decision out of the user's hands. Or at least provide a sanity check. Would you be interested in taking a crack at refining your patch in this fashion? I'll be glad to implement this additional sanity check. Do you think it's worth it to remove the database specification from the user, detect the database version, and warn on a missing file? I haven't looked widely enough to see if the database version is used for anything else in that build chain, my instinct is that can probably be torn out, and just auto-detected. If that sounds good, I'll cook up a patch to do that, instead. The more I think abou it, the fewer things the user has to enter (particularly in the current tediously long build/install process), the better. I can't think of any reason why the user would want to specify a different database version at install time, unless he/she knows the contents of those scripts, in which case he/she's fully capable of working around the auto detection. :) Aaron S. Joyner
Re: [OPEN-ILS-DEV] Rewrite of build-db.sh
2008/7/15 Aaron Joyner [EMAIL PROTECTED]: On Tue, Jul 15, 2008 at 9:05 AM, Dan Scott [EMAIL PROTECTED] wrote: snip Sadly, we may have a bit of a collision in one small area, as I committed an initial PostgreSQL 8.3 full text search schema to trunk about 8 hours ago - so if a user doesn't specify a PostgreSQL version for your script, they'll get 8.3 (and probably suffer ignominous failure). Yeah, I saw the patch go in and thought briefly about it. In general, the detection code currently isn't intended to come into play unless there *isn't* a version in place. So, it won't adversely affect 8.2 users at present, assuming they properly specify a database version, Right - and that's the current assumption, so it was indeed an edge case. but if there are no major changes in version 8.4, you won't need to check in a file in the same way that 8.1 and 8.2 had their own duplicated version of the file. On the other hand... that's not too future proof, it's really just intended to help as a best guess to use the last version if one doesn't exist. Note that it's also currently coupled with really big warnings. :) Saw those - I like your style :) The approach I had been thinking about was using the database credentials to do an initial login to the database to grab the server version (SHOW server_version or SHOW server_version_num, whichever is easier to parse) and use that to take the decision out of the user's hands. Or at least provide a sanity check. Would you be interested in taking a crack at refining your patch in this fashion? I'll be glad to implement this additional sanity check. Do you think it's worth it to remove the database specification from the user, detect the database version, and warn on a missing file? I haven't looked widely enough to see if the database version is used for anything else in that build chain, my instinct is that can probably be torn out, and just auto-detected. If that sounds good, I'll cook up a patch to do that, instead. That sounds great to me. The more I think abou it, the fewer things the user has to enter (particularly in the current tediously long build/install process), the better. I can't think of any reason why the user would want to specify a different database version at install time, unless he/she knows the contents of those scripts, in which case he/she's fully capable of working around the auto detection. :) I'm in full agreement with you. There are plenty of other learning opportunities in the install process; the simpler and more robust we can make this, the better. Thanks again! -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Problem With VMware Image
Dan when will you be releasing your new version of the vmware image with 1.2.2.3? - Original Message - From: Dan Scott [EMAIL PROTECTED] To: Evergreen Development Discussion List open-ils-dev@list.georgialibraries.org Sent: Monday, July 14, 2008 3:44 PM Subject: Re: [OPEN-ILS-DEV] Problem With VMware Image Augh. Change the password in /openils/conf/live-db-setup.pl from openils to evergreen and run /etc/init.d/apache2 force-reload. That should fix you up. I'll fix this when 1.2.2.3 comes out (any day now!). Sorry for the frustration. Dan 2008/7/14 Ryan Laverdiere [EMAIL PROTECTED]: Hi all, It seems when i go to the bootstraping scripts and go to any of the links I get an internal server error! -- Dan Scott Laurentian University
Re: [OPEN-ILS-DEV] Rewrite of build-db.sh
Round 2! This adds the following changes to the previously described list: - remove database version entirely from the user interface, down to build-db.sh. This makes minor removals from: - install.sh - config.sh - install.conf.default - Open-ILS/src/Makefile - Open-ILS/src/extras/import/build-oils-db.sh - implement automatic detection of PostgreSQL database version - abort if we can not detect the db version, providing the user with our best guess (it's probably not going to be, but oh well) - maintain fallback in the case of missing fts-config.sql for specific db version, with big shiny warnings adapted to the autodetection - abort if no fts-config.sql files exist Let me know if you have any other handy ideas for making this part of the build process simpler. Have vim, will code. Aaron S. Joyner
Re: [OPEN-ILS-DEV] Rewrite of build-db.sh
Whoops. :) File actually attached...
Aaron S. Joyner
On Tue, Jul 15, 2008 at 10:54 PM, Aaron Joyner [EMAIL PROTECTED] wrote:
Round 2! This adds the following changes to the previously described list:
- remove database version entirely from the user interface, down to
build-db.sh. This makes minor removals from:
- install.sh
- config.sh
- install.conf.default
- Open-ILS/src/Makefile
- Open-ILS/src/extras/import/build-oils-db.sh
- implement automatic detection of PostgreSQL database version
- abort if we can not detect the db version, providing the user with our
best guess (it's probably not going to be, but oh well)
- maintain fallback in the case of missing fts-config.sql for specific db
version, with big shiny warnings adapted to the autodetection
- abort if no fts-config.sql files exist
Let me know if you have any other handy ideas for making this part of the
build process simpler. Have vim, will code.
Aaron S. Joyner
Index: install.sh
===
--- install.sh (revision 10053)
+++ install.sh (working copy)
@@ -123,7 +123,7 @@
WEBDIR=$WEBDIR TEMPLATEDIR=$TEMPLATEDIR ETCDIR=$ETCDIR REPORTERDIR=$REPORTERDIR\
OPENSRF_HEADERS=$OPENSRF_HEADERS OPENSRF_LIBS=$OPENSRF_LIBS OPENILSDIR=$OPENILSDIR EVERGREENDIR=$EVERGREENDIR \
CIRCRULESDIR=$CIRCRULESDIR CATALOGSCRIPTDIR=$CATALOGSCRIPTDIR CGIDIR=$CGIDIR \
- DBDRVR=$DBDRVR DBHOST=$DBHOST DBVER=$DBVER DATADIR=$DATADIR ADMINDIR=$ADMINDIR\
+ DBDRVR=$DBDRVR DBHOST=$DBHOST DATADIR=$DATADIR ADMINDIR=$ADMINDIR\
PENALTYRULESDIR=$PENALTYRULESDIR DBNAME=$DBNAME DBUSER=$DBUSER DBPW=$DBPW XSLDIR=$XSLDIR NEW_OPAC_URL=$NEW_OPAC_URL \
NEW_XUL_PACKAGE_NAME=$NEW_XUL_PACKAGE_NAME NEW_XUL_PACKAGE_LABEL=$NEW_XUL_PACKAGE_LABEL;
Index: Open-ILS/src/sql/Pg/build-db.sh
===
--- Open-ILS/src/sql/Pg/build-db.sh (revision 10053)
+++ Open-ILS/src/sql/Pg/build-db.sh (working copy)
@@ -1,38 +1,130 @@
#!/bin/sh
-# args: {db-host} {db-port} {db-name} {db-user} {db-password} {db-version}
-# echo You may be prompted several times for your database password...
+# ---
+# Store command line args for later use
+# args: {db-host} {db-port} {db-name} {db-user} {db-password}
+# ---
+PGHOST=$1
+PGPORT=$2
+PGDATABASE=$3
+PGUSER=$4
+PGPASSWORD=$5
+export PGHOST PGPORT PGDATABASE PGUSER PGPASSWORD
-PGPASSWORD=$5 PGUSER=$4 PGHOST=$1 PGPORT=$2 PGDATABASE=$3 psql -f 000.english.pg$6.fts-config.sql
-PGPASSWORD=$5 PGUSER=$4 PGHOST=$1 PGPORT=$2 PGDATABASE=$3 psql -f 001.schema.offline.sql
-PGPASSWORD=$5 PGUSER=$4 PGHOST=$1 PGPORT=$2 PGDATABASE=$3 psql -f 002.schema.config.sql
-PGPASSWORD=$5 PGUSER=$4 PGHOST=$1 PGPORT=$2 PGDATABASE=$3 psql -f 002.functions.aggregate.sql
-PGPASSWORD=$5 PGUSER=$4 PGHOST=$1 PGPORT=$2 PGDATABASE=$3 psql -f 002.functions.config.sql
-PGPASSWORD=$5 PGUSER=$4 PGHOST=$1 PGPORT=$2 PGDATABASE=$3 psql -f 005.schema.actors.sql
-PGPASSWORD=$5 PGUSER=$4 PGHOST=$1 PGPORT=$2 PGDATABASE=$3 psql -f 006.schema.permissions.sql
-PGPASSWORD=$5 PGUSER=$4 PGHOST=$1 PGPORT=$2 PGDATABASE=$3 psql -f 010.schema.biblio.sql
-PGPASSWORD=$5 PGUSER=$4 PGHOST=$1 PGPORT=$2 PGDATABASE=$3 psql -f 011.schema.authority.sql
-PGPASSWORD=$5 PGUSER=$4 PGHOST=$1 PGPORT=$2 PGDATABASE=$3 psql -f 020.schema.functions.sql
-PGPASSWORD=$5 PGUSER=$4 PGHOST=$1 PGPORT=$2 PGDATABASE=$3 psql -f 030.schema.metabib.sql
-PGPASSWORD=$5 PGUSER=$4 PGHOST=$1 PGPORT=$2 PGDATABASE=$3 psql -f 040.schema.asset.sql
-PGPASSWORD=$5 PGUSER=$4 PGHOST=$1 PGPORT=$2 PGDATABASE=$3 psql -f 070.schema.container.sql
-PGPASSWORD=$5 PGUSER=$4 PGHOST=$1 PGPORT=$2 PGDATABASE=$3 psql -f 080.schema.money.sql
-PGPASSWORD=$5 PGUSER=$4 PGHOST=$1 PGPORT=$2 PGDATABASE=$3 psql -f 090.schema.action.sql
+# ---
+# Lookup the database version from the PostgreSQL server.
+# ---
+DB_VERSION=`psql -qtc 'show server_version;' | xargs | cut -c1,3`
+if [ -z $DB_VERSION ] || [ `echo $DB_VERSION | grep -c '[^0-9]'` != 0 ]; then
+ cat EOM
+
+* Could not determine the version of PostgreSQL you have installed. Our best *
+* guess was: *
+* $DB_VERSION
+* which didn't make any sense. For assistance, please email *
+* [EMAIL PROTECTED] or join #OpenILS-Evergreen on the *
+* freenode IRC network.*
+
+EOM
+ exit 1
+fi
-PGPASSWORD=$5 PGUSER=$4 PGHOST=$1 PGPORT=$2 PGDATABASE=$3 psql -f 100.circ_matrix.sql
-PGPASSWORD=$5
[OPEN-ILS-DEV] On the merits of init scripts...
I've recently started playing around with Evergreen. Upon installing it on a test machine, and having a power blip the next evening, it dawned on me that there are no canned, ready-to-use, init scripts for starting the OpenSRF services (the usual suspects of osrf_ctl.sh... start_all). By contrast, memcached, postgresql, and ejabberd are all taken care of by the distribution packages, but none of the walk-throughs in the wiki mention an init script, and there's not one readily available in subversion. I had a brief discussion w/ miker and dbs this evening on IRC with regards to why that was, and there was some concerns about restarting a large production environment automatically, and we all agreed that either something custom, or perhaps even nothing at all, was the best way to proceed in a large setting. In the smaller case (testing and development machines, home installs, etc) it seems practical to have something that will work almost all of the time, and keep things in the expected state. This raised a host of questions. What should the init script be called? OpenSRF, as it's starting OpenSRF services (Router, Perl, C), or should it's name be 'evergreen', following a system-oriented naming style instead, as the goal of the script after all is to start up a workable Evergreen system? Personally, I'd lean towards the former, as Evergreen is really more than just the OpenSRF services, but it may be counter-intuitive to some users. As miker alluded to, perhaps a wrapper script with analagous 'start|stop|restart' functionality would be useful. It could check to ensure the appropriate base services are running (postgresql, a jabber server, memcached), perhaps by inspecting the configs to determine everything is correct, and starting services as necessary? Stop / restart would be a bit more tricky, as you wouldn't necessarily want to stop postgresql on the server on a whim (especially on smaller installations, it might be in use by another service). Should there be just one relatively simple universal SysV-style init script? Should there also be multiple init scripts in the style of the various distributions, which leverage additional management features provided by those distributions? Where's the point of diminishing return, there? I'll stop babbling now. I'm exceedingly new to Evergreen, and readily acknowledge that I don't know what's best here. I'd love to hear the insights from others on this list, and if a consensus approach can be found I'll gladly code up something along those lines. To kick off the discussion, how does a simplistic init script for OpenSRF services, which accepts (start|stop|restart), and will likely work on all SysV platforms sound as a starting point? What other features would be interesting for your use cases? Respectfully, Aaron S. Joyner
