[Dbconfig-common-devel] Re: new mailing list for db apps [was: Re: RFC: common database policy/infrastracture]

[Karsten Hilbert]

> the thing is, in most cases database applications don't need those
> extra rights at all.
The application doesn't. It also does not use the GnuMed DB
admin account.

> so, i think what would work best would be to
> give you the means to grant those extra privileges easily.
Well, no. IMO dbconfig-common would need to be postgres, create
the user "gm-dbowner", grant create-db and create-user to
gm-dbowner, and create the database "gnumed" such that it
belongs to gm-dbowner. Only *then* it should run the
bootstrapping script provided by GnuMed ...

> probably
> the easiest way to do that is run these database setup scripts/sql as
> the real db admin,
... which will then do exactly that, eg run as gm-dbowner and
create all the other groups/users/tables/views/what-not.

> okay, i think i understand where you're coming from now.  i think this
> is slightly different in the mysql world; i don't think you can have
> that level of granularity on users at least.
Well... There's a reason we use PostgreSQL ;-)

> should be a problem.  the trickiest part would be the cleanup process
> in removing the package, which might need to take care of the
> extra users/dbs that it created.
I think cleanup should just run the cleanup SQL provided by
GnuMed (doesn't exist yet), then remove the database gnumed,
then remove the database user gm-dbowner.

> dbconfig-common-devel@lists.alioth.debian.org
> discussion.  perhaps it'd be time to move the discussion there?
Agree. Please put me on it or tell me where to go to
subscribe.

> i think the occasional cross-post to d-d might still be appropriate,
Sure.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346