[Dbconfig-common-devel] dbconfig-common pressed question

[Sean Finney]

Hi Anthony,


On Thu, 2011-03-10 at 18:56 -0500, Anthony L. Awtrey wrote:
> I know it is bad form to just email maintainers, but I don't really have
> a bug, just need a pointer to what I'm doing wrong. Feel free to ignore me.

For future reference it's probably best to send this type of mail to the
dbconfig-common mailing list (i've gone ahead and added it).  While it
will probably be the same people having the conversation, this way it
might help the next person who comes across a similar type of problem,
etc.


> I'm trying to build a web-based application appliance for a cloud
> instance. I am using preseeded PXE installs for the OS install to
> simplify my testing. Everything works except the dbconfig-common
> database creation in the preseed. It works properly if I
> install/reinstall the package on a running system with postgresql
> completely installed and running, but I get errors about postgresql not
> running in my preseed logs when the package is installed.
> 
> I've tried using pre-depends to for postgresql to be fully installed
> before installing my package, but I realized after I did that that
> postgresql does not appear to be started in the preseed environment at
> all. It appears to run the first time at the first boot.

Yes, I think during the installation process there might be some kind of
policy-rc.d configuration preventing the database daemon from starting
up.  You'd probably see something similar if you tried to do the same
with deboostrap to install into a chroot.

> I assume I've got the values preseeded correctly, because I get no
> questions when I install or reconfigure manually. Do you have any ideas?
> Maybe some docs or a web site you could point me to?

First off, you should be able to avoid most/all of the preseeding to use
dbconfig-common if you just drop in the dbconfig-common configuration
file for the package.  If preseeding works too, I don't think that it's
necessarily a bad thing, just that i usually find dropping a file in
place is a bit simpler, and less likely to get lost (since debconf is
technically just cached data)

now i haven't been in this situation in a while, and some of the
specifics might depend on what you're doing, so i can only speak in
broad terms.   But i think you'd probably want to do something like the
following:

 * in the installation, ship/create a dbconfig-common config file for
your package (/etc/dbconfig-common/<pkg>.conf) that specifies
dbconfig_install=false.  Make sure this is in place before the actual
package gets installed.
 * in the installation, ship/create a self-deleting "run-once" init
script, which updates the dbconfig config file to set the value to true,
and then dpkg-reconfigures the application (you might find that you need
to preseed another question or two about reconfiguring).  Alternatively,
with cloud systems like EC2 you could use the "user-data" script to get
the same thing done.

alternatively, you could modify the installation setup that you're using
to ensure that postgres does come up/down as it's supposed to, and then
you don't have to do anything, but that is probably even more dependent
on the specifics of what you're doing.

Hope that's helpful, give it a try and let me know how it goes :)



	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/dbconfig-common-devel/attachments/20110313/670a5f97/attachment.pgp>