[Dbconfig-common-devel] Re: dbconfig-common - short question

Tue Feb 7 21:18:54 UTC 2006

On 2/7/06, sean finney <seanius at debian.org> wrote:
>
> hi marcin,
>
> fyi, i'm cc'ing this to the dbconfig-common discussion list...
>
> On Tue, Feb 07, 2006 at 05:09:30PM +0100, Marcin Antczak wrote:
> > But I would like to make it very easy to end user. And I also would like
> to
> > make it installable 'from scratch'.
> > I mean for user that doesn't have mysql-server installed.
>
> the easiest way to do that would be to have your package depend
> on the mysql-server... but i would strongly advise against it,
> and instead mention mysql-server as a Recommends or Suggests,
> and also say something in the Package description like:
>
> <rest of long description>
> .
> This package requires access to a functioning mysql system.  If you
> do not plan on using a remote mysql system then you should install the
> mysql-server package first.
>
> ... or something like that.

Well it is logical but it's pretty complicated for many users. The problem
is that we don't have an option to choose between local and remote server.

By default only localhost is availabe (or I'm wrong but AFAIK I can set
remote host for dbconfig-common only when I use custom config file).

So, this is pretty big problem because we need:

1. allow users to connect to remote servers
2. allow users to connect to local server and set up database without
additional user activity (ie. 'mysqladmin -u root password somepassword').

And while we don't have something like 'conditional dependency' in debian or
ubuntu it is pretty confusing.

We can set mysql-server as dependency but this will reduce an ability to use
database on remote host.

> The problem is that if I add mysql-server as dependency then my package
> > won't install properly.
> > Because I need to add admin password for mysql admin first.
>
> why do you need the admin password for mysql?  if you are using
> dbconfig-common, and your db app just needs to perform some
> basic sql code execution as admin, dbconfig-common will already
> take care of that for you.  a little more information would
> be very helpful to answer this further.

My app doesn't need to perform sql code as admin - admin password is
required on installation stage.
I need admin app to create database for my app. This is why I want to use
password taken from /etc/mysql/debian.cnf

> So, I need to install mysql-server, then mysqladmin -u root password
> > somepassword
>
> you definitely do not want to go changing the mysql root password.
> that would make a lot of people angry...

Well but by default dbc_dbadmin is 'root' so I need root password to
database if I want to setup database.

> The problem is that in Ubuntu - and propably in Debian, too - mysql-server
>
> > is installed as service/daemon
> > and install scripts generates default password and admin account that is
> > different than 'root'.
>
> yes... the root account still exists as well though.

and as I mentioned above root is set as default value of $dbc_dbadmin

> In ubuntu mysql-sever create small file in /etc/mysql/debian.cnf with some
>
> > settings - admin user: debian-sys-maint, and with autogenerated
> password.
> >
> > I seems logical that if I want to automate my package then I can use
> > debian-sys-maint as dbc_dbadmin, and set into
> > /etc/dbconfig-common/packagename.conf.
>
> i've considered using the debian-sys-maint account before, but
> every time i do, i end up deciding not to because the local
> admin may have modified and/or removed it.

Again - it's default value for users that want to use package without any
modifications.
I think that only advanced users with special needs would like to remove
this account.

  one option which
> might be a good compromise would be to have an extra question like
> "should i use the debian maintainance account?" built-in to
> dbc, so the admin is given the choice.

First thing is that user should have a choice to select host. Local or
remote.

If remote - things are pretty simple.
And if local - dbconfig should try to connect. And return error if localhost
is not available (no mysq-server).

This still won't install mysql-server on demand. But it's just a step ahead.

> So my question is: Is there any way to pass admin password to
> > dbconfig-common from script without calling debconf and without any user
> > interaction?
>
> if we did what i mention above, it could be built into
> dbc to copy/use the debian-sys-maint file and pass it internally
> to all mysql-related calls... but this is of course unwritten.
>

So, what's your opinion about it? What do you think about patches?

Btw. There is another thing. Currently if we don't have mysql-server as
dependency we have more issues.

Short example: cacti - it uses dbconfig-common, and it doesn't need mysql
server.

I don't have mysql-server (I don't need one). So, let's try:

apt-get install cacti

I get questions about password for user cacti (in fact I even don't know
that it's cacti - I know that because I know dbconfig-common sources and
documentation)

And... that's it - package is installed - no questions about remote host, no
question about mysql-server on localhost. Script will simple install cacti
but then suddenly when trying to run this application on
http://localhost/cacti user get a bunch of warnings:

*"Warning*: mysql_connect()
[function.mysql-connect<http://localhost/cacti/function.mysql-connect>]:
Access denied for user: 'cacti at localhost' (Using password: YES) in *
/usr/share/adodb/drivers/adodb-mysql.inc.php* on line *338"

and then on the bottom of the page:

*"Cannot connect to MySQL server on 'localhost'. Please make sure you have
specified a valid MySQL database name in 'include/config.php'."

I consider myself as advanced user but even for me it's just annoying and
for me this package as 'broken'.

So, please think about it. I understand that we need to provide flexibility
(and user should have an ability to connect to remote host) but also we need
to configure things that "just work".

Regards,
Marcin

*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/dbconfig-common-devel/attachments/20060207/d7652e2a/attachment.html