Re: [Gnumed-devel] trying to bootstrap database on Mac "Cannot bootstrap bundles."

[Karsten Hilbert]

On Wed, Jun 30, 2010 at 11:27:27PM -0700, Jim Busser wrote:

> I downloaded the latest server, and ran as root

So far so good.

> The bootstrapper was unable to import mx.DateTime until I adjusted root's 
> path to align with what MacPorts provided for my own user account.

I wonder whether we still need that. Will test...

OK, we do, for a few special cases. I've been able to remove
it from quite a few others.

> But I then got stuck at a familiar-to-some "cannot bootstrap bundles" 
> message. I thought it was maybe a result of my failure to alter the 
> pg_hba.conf file, which had very few lines in it, and into which I inserted 
> (hopefully at a suitable place) the "local samegroup ..." line:
> 
> *************************************************
> # allow anyone knowing the proper password to
> # log into our GNUmed databases
> local   samegroup      +gm-logins                    md5
> 
> # TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
> 
> # "local" is for Unix domain socket connections only
> local   all         all                               md5

The place is suitable (that is, before the catch-all "local
all all" phrase) but OTOH the catch all was non-dangerously
suitable as well already:

It allowed anyone (all-2) to connect to any database (all-1)
via UNIX domain sockets (local) if they knew the appropriate
password (md5).

It would have been problematic if it had had "ident" rather
than "md5" because that would have required the PG account
"any-doc" to exist in the system as well (be IDENTical).

But the line you added does not hurt either and also
documents an explicit security decision.

For bootstrapping, however, it isn't even necessary :-)

> # IPv4 local connections:
> host    all         all         127.0.0.1/32          md5
> # IPv6 local connections:
> host    all         all         ::1/128               md5
> *************************************************

BTW, is that the *entire* active content of pg_hba.conf ?

If so, yes, the bootstrapper will fail to auto-connect
because it assumes:

- you are running as "root" (which you are) and can then
  su to "postgres" (we have tried to make the su Mac-compatible)

- OR are running as "postgres" (which is not recommended still)

- one can connect without a password (but with IDENT) by
  *being* "postgres" (which the script will try to become
  with help of su)

And the above does not contain a line to allow people
*being* (IDENT) "postgres" to connect without a password.
Thus, a password needs to be supplied - for which the conf
files do contain (disabled) provisions.

So this:

> but even after I used the Enterprisedb applescripts to stop and start 
> postgres the attached log indicates a problem with a failed-to-be supplied 
> postgres password.

entirely fits the picture and Sebastian's advice to set the
postgres password in the .conf files will solve it.

> Could it have anything to do with the failure of Mac OS to support
> 
>       su -c
> 
> ??

It shouldn't be fatal because the only two places we use that is

a) when (non-fatally) sanity-checking for existing databases
b) when (non-fatally) cleaning up stating databases after ourselves

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