[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] trying to bootstrap database on Mac "Cannot bootstrap
From: |
Sebastian Hilbert |
Subject: |
Re: [Gnumed-devel] trying to bootstrap database on Mac "Cannot bootstrap bundles." |
Date: |
Thu, 1 Jul 2010 08:45:42 +0200 |
User-agent: |
KMail/1.13.3 (Linux/2.6.33-6-desktop; KDE/4.4.3; i686; ; ) |
Am Donnerstag 01 Juli 2010, 08:27:27 schrieb Jim Busser:
Did you get my message on it today morning ?
Here is it again
If I remember correctly it will not work out of the box.
I expect a message along the lines : cannot boostrap bundles
If that happens have a look at the log file (bootstrap-latest.log)
Scroll down to the end and have a look at the error.
If 'fe_auth' no password supplied error or something like this appear you need
to manually apply small changes to all the *.conf files
Most conf files have a section where you could add passwords
'# password ='
Try and see if that helps.
> I decided to see how far I could get, without altering Postgres from what
> EnterpriseDb supplies.
>
> I downloaded the latest server, and ran as root
>
> 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.
>
Yes. You can do that. I altered the bootstrap script a little to pick up the
correct python on. But your solution is the better one.
> 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
> # IPv4 local connections:
> host all all 127.0.0.1/32 md5
> # IPv6 local connections:
> host all all ::1/128 md5
> *************************************************
>
looks good.
> 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. On my machine, there exists both a system level
> postgres account and (I am pretty sure, as a part of the Enterprise db
> installer process) a database-level postgres account (whose password I
> also set to postgres).
>
> Could it have anything to do with the failure of Mac OS to support
>
> su -c
>
It is not the reason. The su -c problem only indicates that the backup stuff
included in the script did not work.
> ??
>
> Bootstrapping latest GNUmed database.
>
> This will set up a GNUmed database of version v13
> with the name "gnumed_v13".
> su: illegal option -- c
> usage: su [-] [-flm] [login [args]]
> su: illegal option -- c
> usage: su [-] [-flm] [login [args]]
>
The the password stuff above.
Sebastian