Trying to build 7.0.3 on SCO 5.0.4

Dave Smith <dave@candata.com> writes:

cc -b elf -o ecpg preproc.o pgc.o type.o ecpg.o ecpg_keywords.o output.o
keywords.o c_keywords.o ../lib/typename.o descriptor.o variable.o -lPW
-lgen -lcrypt -lld -lnsl -lsocket -ldl -lm -ltermcap -lcurses -W l,-Bexport
Undefined first referenced
symbol in file
nocachegetattr pgc.o

Hm. Try removing #define DISABLE_COMPLEX_MACRO from
src/include/port/sco.h.

Not sure if the backend will build (or work if built) without that
#define; it depends on whether your compiler is less buggy than the
version that caused someone to put that #define into sco.h originally.
But it's worth a try. Worst case, you might have to build the backend
with DISABLE_COMPLEX_MACRO and remove it only for ecpg. Or you could
use the fix embodied in current sources --- make fastgetattr() a
normal extern routine in heapam.c, instead of a static in heapam.h.
But that'd take a little more work...

regards, tom lane

Dave Smith writes:

I am running with configure --with-perl
make clean
make

cc -b elf -o ecpg preproc.o pgc.o type.o ecpg.o ecpg_keywords.o output.o
keywords.o c_keywords.o ../lib/typename.o descriptor.o variable.o -lPW
-lgen -lcrypt -lld -lnsl -lsocket -ldl -lm -ltermcap -lcurses -W l,-Bexport
Undefined first referenced
symbol in file
nocachegetattr pgc.o
ecpg: fatal error: Symbol referencing errors. No output written to ecpg

Go into src/include/port/sco.h and remove the DISABLE_COMPLEX_MACRO
define.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Ok commented out, did a make clean and it rebuild ok.
Created a user postgre and did an inintdb -D/usr2/broker/database as
that user. Started the postmaster with the -i option. Now when I create
a database ...

createdb company
psql: No pg_hba.conf entry for host localhost, user postgre, database
template1
createdb: database creation failed

now the pg_hba.conf file says
local all trust
host all 0.0.0.0 255.255.255.255 trust

which to me is wide open. I know it is the right config file because if
I edit it and place invalid values I get a bad config file error.

Ideas?

Tom Lane wrote:

Actually, to have it wide open, i think it should be this

#host all 0.0.0.0 0.0.0.0 trust

Michael Fork - CCNA - MCP - A+
Network Support - Toledo Internet Access - Toledo Ohio

On Tue, 21 Nov 2000, Dave Smith wrote:

Michael Fork <mfork@toledolink.com> writes:

Actually, to have it wide open, i think it should be this
#host all 0.0.0.0 0.0.0.0 trust

That *would* be wide open: allow anyone to connect from anywhere.
I think what Dave actually wants is

local all trust
host all 127.0.0.1 255.255.255.255 trust

to allow IP connections from localhost only. Depending on how his
local networking software works, he might also want a host line
mentioning his real IP address.

This is the second report I've seen this week of someone thinking that
host = 0.0.0.0 is the right thing to put in pg_hba.conf. Do we have
some erroneous documentation somewhere that suggests that?

regards, tom lane

Well that is how it ships and other software I have used uses that
notation. It is a moot point though. I changed the pg_hba.conf file as
shown below and get the same error.

Tom Lane wrote:

createdb company
psql: No pg_hba.conf entry for host localhost, user postgre, database
template1
createdb: database creation failed

What happens if you try a user "postgres" instead of "postgre"? :)

Rob Nelson
rdnelson@co.centre.pa.us

No differnt

Robert D. Nelson wrote:

What happens if you connect using TCP/IP?
I think the OSR5 libs have the same issue that UW7 has in the accept
call.

I.E. psql -h localhost

LER

* Dave Smith <dave@candata.com> [001121 13:37]:

No differnt

Robert D. Nelson wrote:

createdb company
psql: No pg_hba.conf entry for host localhost, user postgre, database
template1
createdb: database creation failed

What happens if you try a user "postgres" instead of "postgre"? :)

Rob Nelson
rdnelson@co.centre.pa.us

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Yup. that's it.

createdb --host=localhost company
works fine. Could you elaborate on what the accept issue is?

Larry Rosenman wrote:

* Dave Smith <dave@candata.com> [001121 14:34]:

Yup. that's it.

createdb --host=localhost company
works fine. Could you elaborate on what the accept issue is?

SCO has a bug in accept() of Unix Domain Sockets.  It doesn't set 
SA_FAMILY to AF_UNIX.  Here's a patch for 7.0.3:
$ diff -c pqcomm.c.old pqcomm.c 
*** pqcomm.c.old        Thu May 25 20:26:19 2000
--- pqcomm.c    Sun Nov 12 12:03:25 2000
***************
*** 354,359 ****
--- 354,361 ----
                perror("postmaster: StreamConnection: accept");
                return STATUS_ERROR;
        }
+       if (port->raddr.sa.sa_family == 0)
+               port->raddr.sa.sa_family = AF_UNIX;

/* fill in the server (local) address */
addrlen = sizeof(port->laddr);
$

We've fixed this in 7.1 for UnixWare, now we need to fix it for OSR5
as well.

Peter E:
Can we look into this?

Larry Rosenman wrote:

What happens if you connect using TCP/IP?
I think the OSR5 libs have the same issue that UW7 has in the accept
call.

I.E. psql -h localhost

LER

* Dave Smith <dave@candata.com> [001121 13:37]:

No differnt

Robert D. Nelson wrote:

createdb company
psql: No pg_hba.conf entry for host localhost, user postgre, database
template1
createdb: database creation failed

What happens if you try a user "postgres" instead of "postgre"? :)

Rob Nelson
rdnelson@co.centre.pa.us

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

* Peter Eisentraut <peter_e@gmx.net> [001121 14:58]:

SCO has a bug in accept() of Unix Domain Sockets. It doesn't set
SA_FAMILY to AF_UNIX. Here's a patch for 7.0.3:

We've fixed this in 7.1 for UnixWare, now we need to fix it for OSR5
as well.

Peter E:
Can we look into this?

Is SCO intentionally introducing these bugs into all their OS? Surely no
software vendor can be *that* stupid and miss this.

Haven't a clue. They've said it's a bug, but they haven't released a
patch. I've pointed them at our sources, and they've reproduced it.
I don't have a support contract, so It's *LOW* priority....

LER

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Larry Rosenman writes:

* Dave Smith <dave@candata.com> [001121 14:34]:

Yup. that's it.

createdb --host=localhost company
works fine. Could you elaborate on what the accept issue is?

SCO has a bug in accept() of Unix Domain Sockets. It doesn't set
SA_FAMILY to AF_UNIX. Here's a patch for 7.0.3:

We've fixed this in 7.1 for UnixWare, now we need to fix it for OSR5
as well.

Peter E:
Can we look into this?

Is SCO intentionally introducing these bugs into all their OS? Surely no
software vendor can be *that* stupid and miss this.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Is SCO intentionally introducing these bugs into all their OS? Surely no
software vendor can be *that* stupid and miss this.

Uh...
In my experience as a SCO admin, the answer's a resounding YES. Heck, they
still put users home dir's on /usr instead of /home, so nothing else
boneheaded surprises me anymore.

Rob Nelson
rdnelson@co.centre.pa.us

Michael Fork <mfork@toledolink.com> writes:

However, these lines are in pg_hba.conf, which in my opinion needs should
have a disclaimer in big letters as to exactly the security hole it
creates.

#host all 192.168.54.1 255.255.255.255 reject
#host all 0.0.0.0 0.0.0.0 trust
#
# The above would allow anyone anywhere except from 192.168.54.1 to
# connect to any database under any username.

Well, it does *say* that, but maybe the letters aren't blinking red ;-)

There's no real good reason to use such a damn-fool configuration as
an example anyway, so I've modified the example to show Kerberos
authentication allowed from anywhere. Better?

regards, tom lane

Applied the patch and re-compilied. psql company, now works fine.
I would assume then, that it is the same bug that is in the UW.
Thanks for everyones help.

Larry Rosenman wrote: