Re: RFC: common database policy/infrastracture
On Wed, 15 Dec 2004, sean finney wrote:
On Mon, Dec 13, 2004 at 08:36:19PM +0100, Andreas Tille wrote:
Do you have any hint for me how to help here and according to my
previous mail on debian-devel how can I obtain debconf settings
for the specific package ( db_get gnumed/pgsql/admin-pass )
because I did not understand how you planned to do this.
there's a file in /etc/dbconfig-common per-package that has these
settings in a shell script include format, so you could essentially
do something like
. /etc/dbconfig-common/$package.config
this is to work with the "debconf is not a registry (tm)" philosophy.
this config file is also sourced in all the maintainer scripts, setting
new default values in the .config and is used for the authoritative
values during the other scripts.
Yes, but I do not want to store the password *anywhere* - it could even
be removed from debconf database because it makes no sense to store it
in case the local maintainer changes the database password the value
is absolutely useless in any config file or debconf database. Moreover
it is even a security risk to store a password in an additional place.
So my question remains: How to obtain the admin-pass value for the
database application in question *inside* the postinst script.
Otionally we should remove it from debconf database in the end of the postinst
script.
the only problem i see with "any" is that in the future there may be
more non-sql database types handled this way. in the existing framework
there's a debconf variable package/dbtype which gets the dbtype
in question, which is i think what you'd use. now that i'm taking
a look at what's currently there, i see that i'm not actually writing
this variable to the config file. i think that was originally because
i didn't want it to be something configurable if the package didn't
support it.
the plan as it stands now is to have maintscripts for each dbtype,
and then to also have a central master maintscript, to which you can
feed environment variables such as the supported database types. this
central script would then take those and populate a the dbtype template
as a select question. something like
dbtypes="mysql postgresql"
. /usr/share/dbconfig-common/dpkg/config
Sure. My problem with your current 0.7 version is that yu provide *.mysql
scripts which are about 90% reusable for postgresql. IMHO we should do
something like
{config,postinst,postrm,preinst,prerm}
which source a further file containig special things for the database
in question according to the variable $DBTYPE like
. <installdir>/$DBTYPE/`basename $0`
This avoids mainly doubling of code.
Well, I guess this might be solved by "su" as mentioned above, but
my problem is, who to access the values the user have input in the
debconf questions? I need to know some of these values in the
script.
a ". /etc/dbconfig-common/$package.config" should take care of that.
As I said - I do not want to write passwords into extra files. But if this
file would be created by the config script I could read this file in postinst
and remove the password afterwards from there while keeping the other
values untouched. I did not really tested the dbconfig-common stuff because
I was unsure about the postgresql issue but did I understand you right,
that this file exists after finishing the configure script?
Depends
This declares an absolute dependency. A package will not be
configured unless all of the packages listed in its Depends field
have been correctly configured.
and since the postinst script is where all the db-changing code occurs,
you don't have to worry about whether or not the locales is being run
before the main package, if i'm understanding both you and policy :)
Well, the policy speaks only about *configuration*. But the main database
is installed in the *postinst* script. I did not found anything about the
fact that the postinst from a dependant package has to be installed first.
But the locale part of the database only installs if the main server exists
in the postgresql database.
also, fyi, i have initial postgresql support in the latest version of
the package (0.8, which i haven't uploaded yet, but will be in the next
day or two). the one thing lacking is proper dumping and recovering from
errors, as i haven't spent enough time looking at the pg_dump manpage.
I'd volunteer to check that.
ps: i'm not cc'ing d-d, but feel free to do so in your replies if you
like.
Done, because I think it is interesting also for others.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: