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: https://alioth.debian.org/projects/dbconfig-common/ 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. sean --
Attachment:
signature.asc
Description: Digital signature