Обсуждение: pg_hda.conf

Поиск
Список
Период
Сортировка

pg_hda.conf

От
Bo Lorentsen
Дата:
Hi ...

I have just converted (upgraded) to Oliver's postgresql 7.4 debian
package (and, thanks for a nice package), and the installation went ok
(execpt it did not migrate automiticly, as it usually do), but ..

I can't log onto the database using different user names than the
current unix user id.

Fx. if I am user "www-data" I can't logon to database "wiki" as user
"wiki", but this use to work !

I know the magic is performed in the pg_hba.conf file, and I have been
there adding this :

local   all   all                                  trust
host    all   all    127.0.0.1    255.255.255.255  trust

But I still get this "IDENT" error while loging onto the system, WHY ?

It act like I had written "same user" and not "trust", but only while
using 7.4. And yes I have restarted postmaster after fixing the config
files :-)

I am running debian linux sarge, on a i386 platform, if that helps.

Looking forward to any hint that may help me solve this problem.

/BL


Re: pg_hda.conf

От
Oliver Elphick
Дата:
On Fri, 2003-11-21 at 18:08, Bo Lorentsen wrote:
> Hi ...
>
> I have just converted (upgraded) to Oliver's postgresql 7.4 debian
> package (and, thanks for a nice package), and the installation went ok
> (execpt it did not migrate automiticly, as it usually do), but ..

Automatic update is now controlled by a debconf question; the default
answer is no.

> I can't log onto the database using different user names than the
> current unix user id.
>
> Fx. if I am user "www-data" I can't logon to database "wiki" as user
> "wiki", but this use to work !
>
> I know the magic is performed in the pg_hba.conf file, and I have been
> there adding this :
>
> local   all   all                                  trust
> host    all   all    127.0.0.1    255.255.255.255  trust

Please show all the uncommented lines.  Remember that the *first* match
is what governs.  If an  earlier "ident sameuser" line has matched, your
later additions will have no effect.

> But I still get this "IDENT" error while loging onto the system, WHY ?
>
> It act like I had written "same user" and not "trust", but only while
> using 7.4. And yes I have restarted postmaster after fixing the config
> files :-)

If the old pg_hba.conf was different, the resulting behaviour would
probably be different.  What changes were there between the old and the
new?  (If you had "ident sameuser" in 7.3 (or earlier) you would never
have been able to switch identities -- this has not changed between
versions.)

--
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight, UK                             http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
                 ========================================
     "A new commandment I give unto you; That ye love one
      another. As I have loved you, so ye also must love one
      another.  By this shall all men know that ye are my
      disciples, if ye have love one to another."
                         John 13:34,35


Re: pg_hda.conf

От
Bo Lorentsen
Дата:
On Fri, 2003-11-21 at 23:18, Oliver Elphick wrote:

> Automatic update is now controlled by a debconf question; the default
> answer is no.
Ahh, then I just need to know how to turn this on, as I newer have
altered the debconf data manualy.

Btw. I also did get some debconf warnings, but I did not store them
anywhere (as far as I know). Does it matter that I use your woody
packages on sarge (regarding debconf) ?

> Please show all the uncommented lines.  Remember that the *first* match
> is what governs.  If an  earlier "ident sameuser" line has matched, your
> later additions will have no effect.
Thanks, but I tried to take this in account, but here goes :

# DO NOT DISABLE!
# If you change this next entry you will need to make sure the postgres
user
# can access the database using some other method.  The postgres user
needs
# non-interactive access to all databases during automatic maintenance
# (see the vacuum command and the /usr/lib/postgresql/bin/do.maintenance
# script).
local   all         postgres                                      trust
local   all         all                                           trust
host    all         all       127.0.0.1         255.255.255.255   trust
host    all         all       0.0.0.0           0.0.0.0           reject

> If the old pg_hba.conf was different, the resulting behaviour would
> probably be different.  What changes were there between the old and the
> new?  (If you had "ident sameuser" in 7.3 (or earlier) you would never
> have been able to switch identities -- this has not changed between
> versions.)
Hmm, no changes was really made, but the old file  was overwritten, so I
made a new one that contained what was needed (or at least what was what
I hoped for), and it looks like the old one :-)

/BL


Re: pg_hda.conf

От
Oliver Elphick
Дата:
On Fri, 2003-11-21 at 23:47, Bo Lorentsen wrote:
> On Fri, 2003-11-21 at 23:18, Oliver Elphick wrote:
>
> > Automatic update is now controlled by a debconf question; the default
> > answer is no.
> Ahh, then I just need to know how to turn this on, as I newer have
> altered the debconf data manualy.

As root:
   dpkg-reconfigure postgresql

> Btw. I also did get some debconf warnings, but I did not store them
> anywhere (as far as I know). Does it matter that I use your woody
> packages on sarge (regarding debconf) ?

I don't think so.

> > Please show all the uncommented lines.  Remember that the *first* match
> > is what governs.  If an  earlier "ident sameuser" line has matched, your
> > later additions will have no effect.
> Thanks, but I tried to take this in account, but here goes :
>
> # DO NOT DISABLE!
> # If you change this next entry you will need to make sure the postgres user
> # can access the database using some other method.  The postgres user needs
> # non-interactive access to all databases during automatic maintenance
> # (see the vacuum command and the /usr/lib/postgresql/bin/do.maintenance
> # script).
> local   all         postgres                                      trust
> local   all         all                                           trust
> host    all         all       127.0.0.1         255.255.255.255   trust
> host    all         all       0.0.0.0           0.0.0.0           reject

This certainly isn't the distributed file.  What you have there should
allow any user to connect on the local machine and change his identity
at will.  Is it this file that is giving you trouble?  If this file is
giving you ident errors, it cannot be the file the postmaster is using.

The actual file read by the postmaster is in $PGDATA/pg_hba.conf.  On
Debian, that should be a symbolic link to /etc/postgresql/pg_hba.conf.
If the link has been broken, no amount of editing the wrong file will
fix things!

> > If the old pg_hba.conf was different, the resulting behaviour would
> > probably be different.  What changes were there between the old and the
> > new?  (If you had "ident sameuser" in 7.3 (or earlier) you would never
> > have been able to switch identities -- this has not changed between
> > versions.)
> Hmm, no changes was really made, but the old file  was overwritten, so I
> made a new one that contained what was needed (or at least what was what
> I hoped for), and it looks like the old one :-)

This is the distributed file:

# DO NOT DISABLE!
# If you change this first entry you will need to make sure the postgres user
# can access the database using some other method.  The postgres user needs
# non-interactive access to all databases during automatic maintenance
# (see the vacuum command and the /usr/lib/postgresql/bin/do.maintenance
# script).
#
# TYPE  DATABASE    USER        IP-ADDRESS        IP-MASK           METHOD
# Database administrative login by UNIX sockets
local   all         postgres                                        ident sameuser
#
# All other connections by UNIX sockets
local   all         all                                             ident sameuser
#
# All IPv4 connections from localhost
host    all         all         127.0.0.1         255.255.255.255   ident sameuser
#
# All IPv6 localhost connections
host    all         all         ::1               ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff        ident sameuser
host    all         all         ::ffff:127.0.0.1/128                ident sameuser
#
# reject all other connection attempts
host    all         all         0.0.0.0           0.0.0.0           reject

To allow "www-data" to connect and change identity to "wiki" you would
need to change "sameuser" to a map name and put an associated entry in
pg_ident.conf.  See the manual for details.

--
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight, UK                             http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
                 ========================================
     "Can two walk together, except they be agreed?"
                                     Amos 3:3


Re: pg_hda.conf

От
Bo Lorentsen
Дата:
On Sat, 2003-11-22 at 14:41, Oliver Elphick wrote:
> As root:
>    dpkg-reconfigure postgresql
Thanks !

> The actual file read by the postmaster is in $PGDATA/pg_hba.conf.  On
> Debian, that should be a symbolic link to /etc/postgresql/pg_hba.conf.
> If the link has been broken, no amount of editing the wrong file will
> fix things!
Ok, this was the problem, the link to /etc/postgresql was broken !

> To allow "www-data" to connect and change identity to "wiki" you would
> need to change "sameuser" to a map name and put an associated entry in
> pg_ident.conf.  See the manual for details.
Well, this was my plan two :-) But I need to make this work first !

/BL


solaris9 make failure...libpgport.a

От
Byron Amerson
Дата:
Hi there,

attempting to build postgres-7.4 on a sparc/solaris5.9.

I have sfw's gcc-3.3 and sfw's make-3.8. I also have sfw's readline-1.4
and bison-1.875.

make can not seem to find libpgport.a in postgresql-7.4/src/port.  and
indeed it's not there when I take a look.  What went wrong? do I need to
add this lib from somewhere else(!)?

here is the output from make, which barfs shortly into its process:

# gmake
gmake -C doc all
gmake[1]: Entering directory
`/zfr/usr/local/src/postgresql/postgresql-7.4/doc'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory
`/zfr/usr/local/src/postgresql/postgresql-7.4/doc'
gmake -C src all
gmake[1]: Entering directory
`/zfr/usr/local/src/postgresql/postgresql-7.4/src'
gmake -C port all
gmake[2]: Entering directory
`/zfr/usr/local/src/postgresql/postgresql-7.4/src/port'
ar crs libpgport.a isinf.o getopt_long.o qsort.o path.o sprompt.o thread.o
gmake[2]: ar: Command not found
gmake[2]: *** [libpgport.a] Error 127
gmake[2]: Leaving directory
`/zfr/usr/local/src/postgresql/postgresql-7.4/src/port'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory
`/zfr/usr/local/src/postgresql/postgresql-7.4/src'
gmake: *** [all] Error 2

any help or insight would be much appreciated. Thanks.

Byron Amerson
MS student
University of Washington
Department of Earth and Space Sciences


Re: solaris9 make failure...libpgport.a

От
Tom Lane
Дата:
Byron Amerson <byronea@u.washington.edu> writes:
> gmake[2]: Entering directory
> `/zfr/usr/local/src/postgresql/postgresql-7.4/src/port'
> ar crs libpgport.a isinf.o getopt_long.o qsort.o path.o sprompt.o thread.o
> gmake[2]: ar: Command not found

[ scratches head... ]  Surely you've got "ar"?  Maybe it's not in the
default search path?

            regards, tom lane

LDFLAGS and libstdc++ on osx10.3.1

От
Byron Amerson
Дата:
Thanks Tom, for your answer to my question about building on Solaris, I
found ar in a directory not in my path, and built GNU's implemtation as
well.

I now have a question regarding setting the environment variable LDFLAGS
and libstdc++ on osx10.3.1.

Postgis needs postgresql to be configured and built with
LDFLAGS=-libstdc++.
Things build fine but break when attempting to add postgis' goodies to a
database, complaining about postgis' shared libs.  Evidently postgreql is
not linking againts mac's libstc++ which is static (libstdc++.a).

Is there a work around? Or an obvious solution? I built a fresh set of
libs using gcc source, and end up with shared(?)libs with .la extensions
-libtool stuff.  Can I somehow use libtool to link the libs?

Thanks for any help on this issue.

Byron Amerson
MS student
University of Washington
Department of Earth and Space Sciences


Re: LDFLAGS and libstdc++ on osx10.3.1

От
Tom Lane
Дата:
Byron Amerson <byronea@u.washington.edu> writes:
> Postgis needs postgresql to be configured and built with
> LDFLAGS=-libstdc++.

I think you should be asking the Postgis guys about this one.  Any fix
would be in their build process, not ours.

            regards, tom lane