[Dbconfig-common-devel] few questions

[sean finney]

On Fri, May 14, 2010 at 08:16:54PM +0200, Nenad Tomasevic wrote:
> first of all, excuse my bad english, I'm not native speaker.

dobar dan :)

> - is it possible to make installation when database isnt on the same
> machine as web frontend?

yes, though by default the user doesn't see these questions.  take a
look in /etc/dbconfig-common/config and you should see a setting
called dbc_remote_questions_default.

> My dbc_load_include_args looks like "--dbname=database_default
> --dbpass=database_password --dbuser=database_username
> --dbserver=database_hostname" but during installation there isnt any
> questions about database host and/or port..

if this is a first-time packaging i don't think you need dbc_load_include.
this is usually used when you are loading config from a config file that
already exists because the package existed before the dbconfig-common
support was introduced.

> -  I've was trying to get application use template file created by
> dbc_generate_include but there is no values for database host and
> port in that file which is a problem even with installation on
> localhost because application expects some value and I must edit
> that file with hand if I want to be used.

for mysql there's a difference between supplying no host and port (i.e.
use local unix socket in /var/run/mysql) and supplying localhost:3386.
actually, i think mysql traditionally "optimizes out" localhost, and you
have to supply the ip address instead of the name "localhost", but my
memory is a little fuzzy here.

anyway, i think the simplest way around the problem is to patch the app
to behave the way it ought to behave when the host/port are empty.  i guess
there's a number of ways to do that which aren't so sketchy and would
probably be accepted by an upstream author.

but if that's not an option, a much more hacky way of solving it would be
to use dbconfig-generate-include to generate an "intermediate" file in shell
syntax, and then in your postinst you source it after it's been generated,
and then manage creating the actual file and ucf-registering it yourself.
but i'd say the first option is simpler, since we're talking like probably
4-5 lines of perl code slipped in somewhere--it could even be in the config
file itself, if you used the template output option.  you could have the
template say something like

 $dbhost = "_DBC_DBSERVER_";
 if ( ! $dbhost ) { $dbhost = "localhost"; }

> So is it possible to force dbconfig-commom to write those values?
> Also, if nothing of the above isnt possible, is it very wrong to
> make package which will use already included postinstallation script
> for configuring database over web interface after installation and
> not with dbconfig-common?

well, if they already have something it's worth giving consideration,
especially if it has some support built into the web interface (i.e. user
installs app and goes to the web interface to do setup).  cacti, for example,
has great support for schema updates via the web interface, so i have
the package use that instead of dbconfig-common's upgrade support.


	sean

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/dbconfig-common-devel/attachments/20100514/51335c1e/attachment.pgp>