Opened 12 years ago
Closed 12 years ago
#324 closed defect (fixed)
initpetascopedb - error creating plpgsql language
| Reported by: | Owned by: | Dimitar Misev | |
|---|---|---|---|
| Priority: | major | Milestone: | 8.4 |
| Component: | petascope | Version: | 8.4 |
| Keywords: | Cc: | mantovani@… | |
| Complexity: | Medium |
Description
Hi,
I have a new bug introduced in the 8.4-rc1 and his solution
The following command failed when try to execute "createlang plpgsql dbname"
# /etc/init.d/rasdaman initpetascopedb
update_petascopedb.sh: postgres settings read from /etc/rasdaman/petascope.properties
update_petascopedb.sh: user: tomcat6
update_petascopedb.sh: port: 5432
update_petascopedb.sh: db: petascopedb
update_petascopedb.sh: no petascope database found, creating… ok.
createlang: language installation failed: ERROR: must be owner of database petascopedb
update_petascopedb.sh: failed creating PL/pgSQL extension in PostgreSQL, please install it first on your system.
update_petascopedb.sh: exiting.
"createlang plpgsql" must be executed by "postgres" user, not by "rasdaman" user
To solve the issue, change line 206 in file /etc/init.d/rasdaman as follow:
— $SU -l rasdaman -s "$rasshell" -c "update_petascopedb.sh"
++ $SU -l postgres -s "$rasshell" -c "update_petascopedb.sh"
# /etc/init.d/rasdaman initpetascopedb
update_petascopedb.sh: postgres settings read from /etc/rasdaman/petascope.properties
update_petascopedb.sh: user: tomcat6
update_petascopedb.sh: port: 5432
update_petascopedb.sh: db: petascopedb
update_petascopedb.sh: no petascope database found, creating… ok.
update_petascopedb.sh: executing updates:
update_petascopedb.sh: update 0… ok.
update_petascopedb.sh: update 1… ok.
update_petascopedb.sh: update 2… ok.
update_petascopedb.sh: update 3… ok.
update_petascopedb.sh: update 4… ok.
update_petascopedb.sh: update 5… ok.
update_petascopedb.sh: update 6… ok.
update_petascopedb.sh: update 7… ok.
update_petascopedb.sh: updated database to update 7
update_petascopedb.sh: done, exiting.
Ciao
Damiano
Change History (6)
comment:1 by , 12 years ago
| Component: | petascope → RPM |
|---|---|
| Owner: | changed from to |
| Status: | new → assigned |
comment:2 by , 12 years ago
| Component: | RPM → petascope |
|---|---|
| Milestone: | → 8.4 |
| Owner: | changed from to |
| Status: | assigned → accepted |
comment:3 by , 12 years ago
I think it's best if the rasdaman user in postgres is granted the language creation access?
comment:4 by , 12 years ago
If you prefer to run the script "/usr/bin/update_petascopedb.sh" as rasdaman user you can fix this issue adding the "-U" parameter to the "createlang" command
Edit row 179 of "/usr/bin/update_petascopedb.sh" as follow:
— createlang plpgsql $PS_DB:
++ createlang plpgsql $PS_DB -U $PS_USER
Tested:
# /etc/init.d/rasdaman initpetascopedb
update_petascopedb.sh: postgres settings read from /etc/rasdaman/petascope.properties
update_petascopedb.sh: user: tomcat6
update_petascopedb.sh: port: 5432
update_petascopedb.sh: db: petascopedb
update_petascopedb.sh: no petascope database found, creating… ok.
update_petascopedb.sh: executing updates:
update_petascopedb.sh: update 0… ok.
update_petascopedb.sh: update 1… ok.
update_petascopedb.sh: update 2… ok.
update_petascopedb.sh: update 3… ok.
update_petascopedb.sh: update 4… ok.
update_petascopedb.sh: update 5… ok.
update_petascopedb.sh: update 6… ok.
update_petascopedb.sh: update 7… ok.
update_petascopedb.sh: updated database to update 7
update_petascopedb.sh: done, exiting.
comment:5 by , 12 years ago
| Owner: | changed from to |
|---|---|
| Status: | accepted → assigned |
Looks like its better to grant the privileges to the rasdaman user then when initializing via the init script then.
comment:6 by , 12 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Looks like database preparation script is not part of the packaging, its executed but not successful. I can also confirm the issue but solved it granting language creation rights (actually admin ones) to the user running rasdaman, which should be parameterized in the script anyway.
If it is ok to move to the system user for adding the language we have also to take care that its working on wide range of systems, is the postgres user always the same or does it takes different names as the server instance does?