[Dbconfig-common-devel] Why is dbconfig-common asking for the password of the database's?administrative user?

[sean finney]

hi xavier,

On Wednesday 02 April 2008 04:02:52 pm Xavier Luthi wrote:
> My sponsor has a bug opened [1] on gallery2 package because the
> installation scripts "should" use /etc/mysql/debian.cnf instead of asking
> the database root password...
>
> In the bug description, it's even written that:
> "
> [...] gallery2 should simply use /etc/mysql/debian.cnf
> which is automatically generated for the explicit purpose of being used
> by Debian scripts.
> "

if by "debian scripts" he/she means the maintainer scripts of other packages, 
then he/she is wrong :) (i say that while wearing my 
official-but-slightly-dusty mysql package maintainer hat)  

note that the user in debian.cnf is not actually root, but instead 
debian-sys-maint.  the purpose of this user is not to make packagers' lives 
easier, but to provide a stable and reliable way for the mysql package to do 
things like start/stop the service and run cronjobs.  so it's to *those* 
scripts that README.Debian refers.

in default installs atm, this user does have admin privileges, and indeed it 
will probably work.  but it's not the intended use for the account, hence the 
trepidation of "just doing it" without careful review.

> It's a bit confusing for me...  Maybee I'll have to dig a bit more into
> mysql and dbconfig-common to figure out what's the actual best way to use
> this file...

this is kinda how i picture it working:

there should be a new global like dbc_mysql_debian_sys_maint , which can 
default to true.   then in dbc's postinst script (not the package using 
dbconfig-common), assuming it has not explicitly been set to false, dbc 
checks to see if the account works and has the appropriate grants for local 
administrative tasks.  if it fails, the value is set to false before the 
global config file is updated via ucf.

in the config hook for the *package* (.../dpkg/config) dbc will examine
the value of this variable and if set to true will skip the admin password 
question in the case of local installation.  since the config script gets run 
a second time by the postinst, it should be able to pick up a change from 
true->false found by dbconfig-common if they're installed out-of-order.  
there will also need to be an additional "should we not try even if set to 
try" field, set by the error hook in the case of failure later on (i.e. 
failure, followed by a reconfigure/retry)

i haven't fully thought this through, but i think the above seems fairly 
reasonable, though it's still in the "remains to be implemented" category.


	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/dbconfig-common-devel/attachments/20080402/819b30d9/attachment.pgp