[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: common database policy/infrastracture

hey andreas, karsten,

sorry for the delay, i've been doing a fairly good job of distracting
myself with half-life 2 in the past week :)

On Thu, Dec 16, 2004 at 05:30:30PM +0100, Andreas Tille wrote:
> The applilcation I want to package comes with a quite complex bootstrap
> script which does *all* setup (including creating the database and
> adding an admin account).  So what we could do here:
>     1. From a Debian point of view provide an option for debconf which
>        just tells postinst not to create the database etc, because
>        the bootstrap script would take over this job.
>        Just provide the data which are needed in a defined interface
>        instead.

this would certainly be possible, and as we've discussed there are
already hooks for this.  however, i think it's good practice to
isolate what needs to be done with administrative privileges
if at all possibile.

>     2. From the application point of view I could ask people to
>        include an option which prevents the bootstrap script from
>        doing the work which is just done.  I guess this is no big deal
>        for the very responsive authors.

i really think this would be ideal.  patching the already existing
installer script to have a --noadmin option would then let the bulk
of the work remain in the script (which gives you the benefit of
still having something that works on non-debian systems),

> >take a look at 0.8 :)
> URL?
> I hope you would announce new versions or just move the package to
> experimental to keep people informed.

i can continue uploading debs to experimental if you'd like.  currently
the authoratative source of the latest version is:

deb http://people.debian.org/~seanius/policy/examples/ ./
deb-src http://people.debian.org/~seanius/policy/examples/ ./

also, i've started an alioth project:


to which i've migrated my cvs tree for the project.  i've also
started a mailing list, so if there's sufficient interest we
could use that as a channel for announcements/commits.

> >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
> While this is only cosmetics I would prefer storing the database
> specific stuff in separate directories.  If we will have more databases
> it would be more easy to read.

folks shouldn't need to read it :)

> >for the admin pass, it should be configurable globally whether or not
> >the admin password is stored at all.
> This would be nice.

and it's definitely on my roadmap.  there are also other
security-related shortcomings that still need to be addressed,
mostly with passing information on the command line (or storing
sensitive data in the environment at all, for that matter).

> >i'm not against providing a way around that, however, if there really
> >is a situation in which you wouldn't need the password.
> If all else fails: dd if=/dev/zero of=/dev/hda   ;-)

that's a sure way to secure your system, too!

> >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.
> Well, if this is really the case than it would save a certain amount
> of time for me.  While I think this is a perfectly reasonable
> requirement I remember times were this was not the case and I had
> trouble to work around this.

someone will need to clarify this, but i believe it is the case.  i
know that the biggest problem with the package configuration process
is that the pre-configuration doesn't have any guarantees about
dependencies, which makes it difficult to use anything outside
of base in the .config scripts.

On Fri, Dec 17, 2004 at 11:47:00AM +0100, Karsten Hilbert wrote:
> > >but something to point out:  dbconfig-common already performs the
> > >administrative actions needed to set up the database and database user
> Well, see, the GnuMed bootstrapping does a lot more advanced
> things regarding "the database user". There's users and groups
> with varying levels of access to the database.

are these actual mysql/pgsql database users, or users stored inside the
gnumed database?  currently, dbconfig-common doesn't do anything for the
latter, and i don't know that it's a generalizable enough of a problem
that it's worth trying.  however, it provides you a way for setting up
the database with whatever you want to put into it.



Attachment: signature.asc
Description: Digital signature

Reply to: