gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] feedback re server bootstrap


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] feedback re server bootstrap
Date: Sat, 5 Nov 2005 12:33:31 +0100
User-agent: Mutt/1.5.9i

On Tue, Nov 01, 2005 at 06:49:41AM +0800, Syan Tan wrote:

> finally got bootstrap to run:
:-)

> feedback items:
>  1. Postgresql 8.0 has "clusters" on linux, which should run on different
> ports, but can be used for alternate "clusters" if using the same
> port but then no way to know which "cluster" is running after a while. 
> Sometimes pg_ctlcluster doesn't stop the running cluster,
> because of invalid pid in postgres.lock ( due to machine being switched off
> instead of shutdown ?) so have to manually "ps -A | grep postmaster"
> and "kill" the PID number of the first postmaster process.
Seems a distribution related problem. Have you reported this
to your distro/the PostgreSQL team (in case it's a
pg_ctlcluster bug) ?

I noticed the "cluster" support on recent Debian/testing,
too, which led me to discover one missing robustness check
in our bootstrapper: The Debian upgrade procedure had a bug
in failing to properly upgrade the plpgsql language path and
failed to notify DBAs about a possible need to fix that
manually (even with the proper fix this may be necessary).

> 2. pg_hba.conf  misconfigured. Despite the nice message in bootstrap log, it's
> quite possible to misconfigure pg_hba.conf and
> make it hard to  diagnose where the bootstrap python program fails.
While surely a problem not much we can in principle do about
it short of documenting the requirements.

> postgresql
> 8.0 allows the possibility of having an alternate
> cluster , so that it's not a "no-no" to copy a standard pg_hba.conf for gnumed
> to a specific gnumed-only cluster ( because template1
> etc... is not going to be used for any other application).
That's certainly one way of doing it - the perfect
opportunity for a company to make some money !

> 3. plpgsql  bootstrap may fail, no option or hint to manually install
> plpgsql.
Bootstrap automatically installs plpgsql for you if that's
needed. If it doesn't it's a bug.

> the command line "createlang plpgsql -U postgres template1"
> fixes this problem quite easily on my installation of postgres 8.0 , even
> thought the bootstrapper can't find the plpgsql.so in the /lib directories.
So, what IS the directory on your machine ?

>  4. Two boostrapping entities can be a pain.  Having a gm-dbo owner and a
> postgres user with separate passwords can be a problem.
It's standard practice, I suppose. Separation of priviledge.

> It would be easier to tell the user to set the postgres password
"Postgres" doesn't have a system level password. One is
supposed to use "sudo" or "su" to do things as postgres.

Neither does postgres have a database password. You are
supposed to either BE postgres (in which case "IDENT
sameuser" allows access) or be allowed to BECOME postgres
(in which case IDENT ident-map lets you access).

> by doing on a
> bash command line , "su postgres " "psql template1" "alter user postgres
> password 'mypass' "  , and have postgres be the gnumed_v2 database owner,
> then trying to remember if gm-dbo 's password is "gm-dbo" or some other
> password set in a previous attempt to get
> the bootstrapper to run.
> (maybe the bootstrapper should drop the user 'gm-dbo' , and create the user
> 'gm-dbo' with a standard password, and tell the user what the password is , 
> and proceed without asking for the gm-dbo password ).
No, but we should *check* whether gm-dbo already exists and
emit a message to that effect such that people can know
whether they need to know a previous password or invent a
new one.

> 5. bootstrapper log messages may be a little long.
I agree. They capture all the detail needed for remote
diagnostics which has saved our butt on this very list a few
times already. Fixes to improve the situation will, of
course, be considered.

> Maybe the bootstrapper could have a machine readable error log, which is not
> changeable , and anytime a success occurs where
> a  guess at a fix has worked for a previous failure, it should say "previous
> error: ....  *FIXED* "  , so that someone trying to
> get the bootstrapper to run knows which problems are fixed , when there are
> multiple problems stopping the bootstrapper working.
I am not sure I understand.

> thanks for  listening to  my gripes
No problem ! Please keep trying and reporting.

Thanks,
Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

[Prev in Thread] Current Thread [Next in Thread]