[OPEN-ILS-GENERAL] Failing to install 2.1 with separate database

[Joseph Haig]

Thanks. I must have got confused somewhere along the lines because I
thought that all the database creation was done by eg_db_config.pl
even when using a remote database. I ran the create_database.sql on
the other machine and now it has worked.

I have the postgres 9.0 client on the evergreen machine so I don't
know where it is getting 9.1 from.

On 25 October 2011 13:36, Martha Driscoll <driscoll at noblenet.org> wrote:
> Joe,
> I have Evergreen running on one server and postgres 9.0 running on a
> separate server.  On the database server, I download Evergreen-ILS-2.1.0a,
> but you could copy create_database.sql to your database machine.  The
> install instructions also say you can run create_database.sql from your
> evergreen machine, but you need postgresql-contrib-9.0 installed (so you
> have those tablefunc.sql etc files).
>
> On the database server, I ran the create_database.sql script:
>
> cd /home/opensrf/Evergreen-ILS-2.1.0a
> psql -vdb_name=evergreen -vcontrib_dir=`pg_config --sharedir`/contrib -f
> Open-ILS/src/sql/Pg/create_database.sql
>
> The create_database.sql script does the database creation steps which used
> to be in the installation instructions.  Namely,
>
> createdb -T template0 --lc-ctype=C --lc-collate=C -E UNICODE evergreen
> createlang plperl   evergreen
> createlang plperlu  evergreen
>
> psql -f /usr/share/postgresql/9.0/contrib/tablefunc.sql evergreen
> psql -f /usr/share/postgresql/9.0/contrib/tsearch2.sql  evergreen
> psql -f /usr/share/postgresql/9.0/contrib/pgxml.sql     evergreen
> psql -f /usr/share/postgresql/9.0/contrib/hstore.sql    evergreen
>
> You then run eg_db_config.pl on your evergreen server but without the
> --create-database option.
>
> It sounds like you may have postgresql 9.1 client on your evergreen machine
> and 9.0 server on your database machine?  That may be a problem.
>
> I also had to tell postgres to listen for connections on all interfaces in
> /etc/postgresql/9.0/main/postgresql.conf:
>
> listen_addresses = '*'
>
> I also had to allow my other host to connect (it's on the same subnet as my
> database server) in /etc/postgresql/9.0/main/pg_hba.conf:
>
> # Evergreen servers
> # TYPE  DATABASE        USER            CIDR-ADDRESS            METHOD
> host    all             all             samenet                 trust
>
> I hope this helps.
>
> --
> Martha Driscoll
> Systems Manager
> North of Boston Library Exchange
> Danvers, Massachusetts
> www.noblenet.org
>
> On 10/24/2011 4:39 PM, Joseph Haig wrote:
>>
>> A couple of months ago I started playing with the then release
>> candidate of Evergreen 2.1 with Evergreen running on one server and
>> the database on a separate server. When the final release came out I
>> tried to upgrade but I get the following errors when attempting to set
>> up the database:
>>
>> psql:Open-ILS/src/support-scripts/../sql/Pg/create_database.sql:24:
>> /usr/share/postgresql/9.1/contrib/tablefunc.sql: No such file or
>> directory
>> psql:Open-ILS/src/support-scripts/../sql/Pg/create_database.sql:26:
>> /usr/share/postgresql/9.1/contrib/tsearch2.sql: No such file or
>> directory
>> psql:Open-ILS/src/support-scripts/../sql/Pg/create_database.sql:28:
>> /usr/share/postgresql/9.1/contrib/pgxml.sql: No such file or directory
>> psql:Open-ILS/src/support-scripts/../sql/Pg/create_database.sql:30:
>> /usr/share/postgresql/9.1/contrib/hstore.sql: No such file or
>> directory
>>
>> First of all, I am using Postgres 9.0 but this is besides the point.
>> /usr/share/postgresql/9.*/contrib does not exist on the local machine
>> because the database is remote. This file create_database.sql does not
>> exist in RC2 (the last release candidate I tried) so I am wondering
>> where it has come from. Also, "diff -y
>> Evergreen-ILS-2.1.0a/Open-ILS/src/support-scripts/eg_db_config.pl
>> Evergreen-ILS-2.1-RC2/Open-ILS/src/support-scripts/eg_db_config.pl"
>> shows that the eg_db_config.pl script has been modified since the
>> release candidate to run this extra sql script.
>>
>> Can someone suggest a work-around so that I can get back to the
>> behaviour that was in the release candidate. Thanks.
>>
>> Regards,
>>
>> Joe
>
>