Thread: Trying to build 7.0.3 on SCO 5.0.4
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 make[3]: *** [ecpg] Error 1 make[3]: Leaving directory `/tmp/postgresql-7.0.3/src/interfaces/ecpg/preproc' make[2]: *** [all] Error 2 make[2]: Leaving directory `/tmp/postgresql-7.0.3/src/interfaces/ecpg' make[1]: *** [all] Error 2 make[1]: Leaving directory `/tmp/postgresql-7.0.3/src/interfaces' make: *** [all] Error 2
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: > 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
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: > 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: > > > 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 >
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: > 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
>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: >> 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
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: > 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 >>
* 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
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/
* 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
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
>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
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:
> * 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
>>>>