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" <[email protected]>
To: "Yair Zaslavsky" <[email protected]>
Cc: [email protected]
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
[email protected]
http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/users
