[Top][All Lists]
[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Gnumed-devel] feedback re server bootstrap,
Karsten Hilbert <=