[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: common database policy/infrastracture



On Mon, Oct 18, 2004 at 09:19:28AM +0200, Javier Fernández-Sanguino Peña wrote:
> [That should be http://people.debian.org/~seanius/policy/dbapp-policy.html, 
> BTW]

oops!

> I'm missing some "Best practice" on how to setup the database itself. That 
> is, how to setup the tables (indexes, whatever...) that the application 
> will use from the database and, maybe, even some initial data in some of 
> the tables.

i hadn't addressed that yet because it's very specific to the database
type, and i was starting from a more general perspective.  my approach
is to first decide on what the appropriate package behavior is, and then
sort out the technical details on how to get a package to behave
such.

> One common issue is that the application depends on that in order to work 
> and it's not done automatically. Maybe the user is prompted to do it but he 
> might be unable to do so until the installation is finished. For an example 
> of this problem see #205683 (and #219696, #265735, #265878). 

that's pretty funny, but exactly the kind of stuff we're trying to
avoid.

> It might be good to provide a common mechanism to setup the database so
> that users are not asked to run an SQL script under /usr/share/XXX (usually
> doc/package/examples). Maybe even defining a common location for these
> (/usr/share/db-setup/PACKAGE/XXXX.{mysql,pgsql}?). Notice that the SQL
> script that needs to be run might difer between RDBMS. 

in addition to the sql, the process of adding users or accessing the
database will differ too.  

On Mon, Oct 18, 2004 at 11:30:59AM +0100, Oliver Elphick wrote:
> If the database supports SQL transactions (as PostgreSQL does), SQL
> scripts should do everything inside a transaction, so that either all
> objects are successfully created and populated or else there is no
> change at all to the database.

good idea.

> It is, however, quite possible for the application installation to fail
> because of circumstances beyond the packaging system's ability to
> manage.  Therefore, the package installation scripts need to be able to
> report what further steps are needed in order for installation to be
> completed.

again, good idea.

On Mon, Oct 18, 2004 at 09:08:35AM +0100, Oliver Elphick wrote:
> > for the admin password, i agree.  for the app_user password, i think
> > most apps are storing this password in a cleartext file for the
> > application to use (php web apps, for example).  that's my opinion,
> > anyways.
> 
> That may differ per application.  I would argue that it is very bad
> security in all circumstances.

well, i suppose we could always ask the admin if they want to store
the passwords...


	sean

-- 

Attachment: signature.asc
Description: Digital signature


Reply to: