|Subject:||[Gnumed-devel] feedback re server bootstrap|
|Date:||Tue, 01 Nov 2005 06:49:41 +0800|
finally got bootstrap to run:
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.
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. 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) .
3. plpgsql bootstrap may fail , no option or hint to manually install plpgsql. 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.
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 would be easier to tell the user to set the postgres password 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 ).
5. bootstrapper log messages may be a little long. The actual error is 2 pages up from the end of the log after doing a "cat" of the log.
The error should be visible after doing a "cat" or a "tail" on a standard display area terminal.
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.
This should output to the console , and also the fatal error that stops the bootstrapper should output to the console, rather than
having to , *groan* , search the log.
thanks for listening to my gripes, but otherwise keep up the good work with gnumed.
|[Prev in Thread]||Current Thread||[Next in Thread]|