Hi Christian, Sorry for the late response, I was focusing on more severe issues than this wish-list bug.
On Fri, 21 Aug 2015 10:35:57 +0200 Christian Seiler <christ...@iwakd.de> wrote: > If connection to the database server fails on postinst of a > dbconfig-common package, it currently just prints an error. It would be > great if dbconfig-common could write out a SQL file with all the > commands it wanted to execute (including CREATE DATABASE / CREATE USER) > to a well-defined location so that the administrator may easily rerun > this once the database server is available again. Exactly for this purpose dbconfig-common (and its connected policy) recommend it to each package to DOCUMENT this in /usr/share/doc/<package>/ (The draft policy for database applications says in 1.4.1: """With this in mind, directions for manually installing (and upgrading if relevant) the database must be included in the documentation for the package.""") E.g. for cacti it is described in /usr/share/doc/cacti/README.Debian.gz The unfortunate thing is that for dbconfig-common to be able to support this, it needs a full redesign because it processes items sequential. So it only nows about the next couple of actions, not necessarily all of them. > The error message shown should contain the path of the file and the > command the administrator should execute once the server is up. dbconfig-common could of course point to the scripts it would be going to execute itself, e.g. the files in /usr/share/dbconfig-common/data/<package>/*/<dbtype>/. But also print db creating scripts and user creating scripts. Not fully sure if this is what you mean. > Two use cases (as per our discussion at DebConf): > > - remote servers may be down during the installation of a > dbconfig-common utilizing package - but the administrator might > want to use dbconfig-common here to simplify the setup - and > having to just run a simple command they can copy/paste from the > error message once the server is up again would be simpler than > manually configuring the package I guess this use case would be mostly served by the knowledge of path of the install script of the package. > - provisioning of VMs/Containers: in some setups, containers/VMs can > be provisioned automatically (via script) by debootstrap'ing into > a chroot, then dropping a /usr/sbin/policy-rc.d there to disable > service starts and then installing all packages. For the vast > majority of packages this works, but obviously the database server > won't be running in this case, so dbconfig-common won't work there. > If dbconfig-common were to just put SQL files for all applications > that use the database to some well-defined location, one could add > support to the provisioning script to manually run them at a later > point - so that installing everything there would still work > automatically. Apart from the db/user creation, I think this can already be done by design of dbconfig-common. > It would be great if dbconfig-common could support that. I agree, but it is not going to happen in the way you described. I hope we can still get closer than the current situation. Paul
signature.asc
Description: OpenPGP digital signature
