Hi Ian You're right in that superuser privileges are required to make this work. But it would rarely happen that remote DB admin would give you a user with super privileges. The solution we've come up with is this:
1. Use (or tell remote DB admin to do so) the psql command to load the extension functions to template1 DB on remote DB server: psql -U postgres -d template1 -f /usr/share/pgsql/contrib/uuid-ossp.sql 2. Now, all newly created databases will include extension functions. template1 is a special DB in postgres. In fact, when you create a new DB, it is actually copied from template1 with a new name. This way, we can still work with the user that has no superuser privileges in the remote DB server. ----- Original Message ----- From: "Ian Levesque" <i...@crystal.harvard.edu> To: "Yair Zaslavsky" <yzasl...@redhat.com> Cc: users@ovirt.org Sent: Wednesday, August 15, 2012 12:30:16 AM Subject: Re: [Users] New engine install on remote DB fails "uuid-ossp extension is not loaded" > Here's what the install log tells me: > > 2012-08-14 11:56:12::INFO::engine_validators::425::root:: Successfully > created temp database on server cmcd-web. > 2012-08-14 11:56:12::INFO::engine_validators::443::root:: Checking that uuid > extension is loaded by default on the remote server > 2012-08-14 11:56:12::DEBUG::common_utils::350::root:: running sql query > 'SELECT uuid_generate_v1();' on db server: 'cmcd-web'. > 2012-08-14 11:56:12::DEBUG::common_utils::286::root:: cmd = /usr/bin/psql -h > cmcd-web -p 5432 -U ovirt -d ovirt_engine_test -c "SELECT uuid_generate_v1();" > 2012-08-14 11:56:12::DEBUG::common_utils::291::root:: output = > 2012-08-14 11:56:12::DEBUG::common_utils::292::root:: stderr = ERROR: > function uuid_generate_v1() does not exist > > So, the installer is trying to create a database "ovirt_engine_test" and > succeeding. But until you run `psql -U postgres -d <database_name> -f > /usr/share/pgsql/contrib/uuid-ossp.sql`, the function uuid_generate_v1() > won't be available. Therefore, the temporary database the installer is using > to determine compatibility fails. The problem ended up being that the postgres role which ovirt is using needs to have superuser privileges. Once I granted superuser to the "ovirt" role I created, all worked well. ~irl _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users