On Sun, 25 May 2003, Matt Zimmerman wrote:
> For python, you only need to declare Depends: python to ensure that python
> is installed and configured when your postinst runs.
Are you sure that the python interpreter is working if python is just installed
at the same time (apt-get run) in which GnuMed is installed. You just
negated the "predepends-question" and thus I think you have thought about
that when writing this answer.
> postgresql is more complex, because (presumably) you want to allow for a
> remote database. If so, you must prompt the user for the hostname,
> authentication information, etc. and fail if you are unable to connect to
> it. If you only support a local database, you can just depend on
> postgresql-server or whatever is appropriate.
I will split the GnuMed package into several binary packages. Currently
I'm talking about the server package which installs a database on localhost.
But I have to relay that postgresql-server is up and running when the
postinst of gnumed-server is starting.
> I believe someone is working on a python debconf interface, but I do not
> know its status. You can probably find out with some searching and email.
There was an announcement and ... silence.
> If you store the password in a temporary file, make sure that you do it
> securely, using e.g. $(tempfile -m 0600) so that it is created with O_EXCL
> and secure permissions before you try to put any data into it.
Yes, this is what I just implemented. This will do the trick as long I will
wait for the Python interface. (Sorry I just wait because I'm not competent
enough to push the development.) I guess this Python interface will be ready
right in time before GnuMed reaches production state.
> > This ends in
> > psql: FATAL: IDENT authentication failed for user "mytestuser"
> >
> > Now I would llike to know the following two things:
> > 1. How to change the postgresql configuration in a way which just
> > adds minimum off additional rights?
> > 2. How to accomplish this change?
>
> Presumably you use a GRANT command as in ANSI SQL92. The specifics may be
> slightly different for postgresql's unix socket authentication; I am not so
> familiar with it.
I guess this is not the reason for the problem. It is an authentication
problem as some further tests I tried show clearly. Some magic has to be
done in /etc/postgresql/pg_hba.conf but I did not found a reasonable way
to continue enabling the prefered ident method with password/crypt for this
single (and perhaps further) users.
Kind regards
Andreas.
