On Thu, Dec 16, 2004 at 08:27:20AM +0100, Andreas Tille wrote:
> 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.
well, the admin pass shouldn't be stored anywhere, or at least the
admin should be prompted whether or not the admin pass should
be stored. this is not the current behavior of dbconfig-common,
but it is the planned behavior.
> 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.
ah. the short answer for the time being is that there's a variable
dbadmpass, which will have the answer stored. if your application
wants to get the admin password too, i don't see any problem with doing
a db_input/db_get again on the admin password question (it is a question
belonging to your package, after all), though if the password isn't
stored the admin could be prompted twice.
but something to point out: dbconfig-common already performs the
administrative actions needed to set up the database and database user
in the first place, so does your package even need the admin password?
> 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`
take a look at 0.8 :) this was the plan all along, but i had to start
with what i knew. also, i discovered that you can't reliably use
$0 in the maintainer scripts because when a package is first
preconfigured before being unpacked the filename doesn't follow
the same naming scheme. but now there are subscripts for
the supported mysql and pgsql database types, and a larger common
type (which will eventually support applications that support
multiple db types):
mini-me[~]10:28:00$ ls /usr/share/dbconfig-common/dpkg/
common postinst postrm.mysql preinst.pgsql
config postinst.mysql postrm.pgsql prerm
config.mysql postinst.pgsql preinst prerm.mysql
config.pgsql postrm preinst.mysql prerm.pgsql
> >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?
for the admin pass, it should be configurable globally whether or not
the admin password is stored at all. for the user password, it will
have to be stored in a file somewhere anyway for whatever application
uses the database, so i'm not too concerned about that.
i'm not against providing a way around that, however, if there really
is a situation in which you wouldn't need the password.
> 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.
i believe that when policy speaks of configuration it is in fact
speaking of the postinst script. the .config script is usually
referred to as "pre-configuration". with pre-configuration, it is
true that you can't rely on any dependencies being met, but touching
files in the .config script is generally a bad practice, and i don't do
anything other than ask debconf questions in the config script.
sean
--
Attachment:
signature.asc
Description: Digital signature