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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
