Control: tags -1 moreinfo Hi again,
On Sun, 21 Feb 2016 21:36:16 +0100 Paul Gevers <elb...@debian.org> wrote: > 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. Could you please comment on what would be required for your use cases? Would it be enough to just store the user/db creation script? Paul
signature.asc
Description: OpenPGP digital signature
