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

Re: RFC: common database policy/infrastracture



On Thu, 2 Dec 2004, sean finney wrote:

most of the script stuff could be shared in between the two, yeah.  i
designed the system such that it could eventually handle supporting
multiple database types, as well as packages that support multiple
database types themselves.  then, i proceeded to start with what i know :)

currently, i'm using code from wwwconfig-common for doing the actual
db stuff, and there is pgsql support in that package, so i don't think
implementing pgsql support would be initially too hard.
Well, my question is basically: Should I just copy and search+replace
the mysql stuff to pgsql (which is error prone for future changes which
are quite possible) Or should we do something like inserting a variable
in all these scripts for the database and use a parameter or even do
something like

        <script>.any
        ln -s <script>.any <script>.mysql
        ln -s <script>.any <script>.pgsql
        ln -s <script>.any <script>.<whatever>

and obtain the database from $0 ?

so dbconfig-common provides two hooks for running
install/bootstrap/upgrade code.  the first is just a plain sql file,
the second is a shell script that can effectively do anything.  i
have not tested the latter at all, but have written code that i
think will work.  the dbconfig-common-using.html document provides
the details.  however, in both cases i don't have it set up to run as
the database administrator, that was really a design choice and not a
limitation, and if it turns out it's not worth it i could have it run
as administrator instead.
I see no problem in providing a script there which runs as root and
does a
          su - <dbadmin> real_bootstrap_script

     db_get gnumed/pgsql/admin-pass
     insert_passwd_into_temporary_config_file $RET
     bootstrap_gnumed_database --config temporary_config_file
     rm temporary_config_file

   My problem is now: How to address gnumed/pgsql/admin-pass in
   your dbconfig-common framework?

the big question in my mind is what about the package needs
administrative access?  this might stem from my not understanding
differences between mysql and postgresql.
Well, I guess this might be solved by "su" as mentioned above, but
my problem is, who to access the values the user have input in the
debconf questions?  I need to know some of these values in the
script.

Moreover I have a further problem:  The database consists of a basic
server and than there are some tables for different locales which I
wnt to provide in different packages (because you need only one locale
package, for instance either for Germany or for Australia but not both).
The problem is, that I have to ensure that the common server is installed
*first* before any locale server would be installed (because the locale
server relay on the existance of certain tables.

However, I can not relay on the fact that dependent packages are installed
in a certain sequence thus it might occure that the postinst ot the
common server was not finished when the locale server postinst is running.
My idea for a solution in the locale postinst was:

  1. check whether common server is existant (and has the right version)
  2. a) if yes run locale bootstrap script
     b) if no, touch /var/run/<packagename>
  3. Install /etc/apt/apt.conf.d/90<packagename> :
     DPkg {
        Post-Invoke {"test -f /var/run/<packagename> && run_locale_server_bootstrap"}
     }
  4. DPkg Post-Invoke cares for locale servers if necessary

What do you think about this?

Kind regards

        Andreas.

--
http://fam-tille.de



Reply to: