[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LedgerSMB-1.3.8 on Suse 12.1 and Postgresql 9.1 setup.pl is not working
- Subject: Re: LedgerSMB-1.3.8 on Suse 12.1 and Postgresql 9.1 setup.pl is not working
- From: Chris Travers <..hidden..>
- Date: Tue, 27 Dec 2011 18:49:15 -0800
On Tue, Dec 27, 2011 at 1:27 PM, Erik Huelsmann <..hidden..> wrote:
> Hi Frans,
> On Tue, Dec 27, 2011 at 2:02 PM, starconsultancy
> <..hidden..> wrote:
>> Dear all,
>> I have tried everything but i cannot fix in order to setup.pl working in
>> proper way.
>> There was initially a problem with getting into the database, because upon
>> with /etc/init.d/postgresql restart; I got message back that this was not
>> Looking into this matter together with Chris we find out that
>> /var/lib/pgsql/data is only to be reached with the command chmod 700 -R
>> /var/lib/pgsql/data. After having done this the postgres could be reached.
>> Also in PgAdminIII it is visible that in principle all is okay.
>> Only the postgresql cannot load ledgersmb.
> Could you post the (error) logs somewhere? That'd help us get an idea
> of the kind of problem you may be running into.
> Also, did you install the base *and* contrib packages? If you're
> missing the contrib package, that's a good reason for failure -- it's
> definitely a requirement.
> What error are you being presented in the browser?
After working with Frans on this a bit here's what I know. I think
there are a few things that are confused in this email.
The initial issue was that PostgreSQL refused to start after changing
the pg_hba.conf. The log messages suggested there was an
authentication failure, and a fast shutdown request was received.
This used to be an issue with Debian but hasn't been for a long time.
What's probably happening is that the startup script is trying to
check if PostgreSQL is in fact running and when it gets an
authentication failed, is shutting down. If this is what is going on,
it's an issue with SuSE startup scripts.
The second issue I think Frans is having is related to attempted
workarounds. To explain: PostgreSQL is very security-paranoid and
refuses to start up when the security environment is believed to be
sane. This means no access to the data files from outside the
postgres user (meaning the 700 permissions on the directories) and
that it will refuse to start as root.