Re: [HACKERS] 7.4.3 8.0.0beta1 + Solaris 9: default pg_hba.conf
Patch applied. Thanks. --- Andrew Dunstan wrote: Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: At this stage of the game I would just change pg_hba.conf.sample to use '127.0.0.1/32' instead of '127.0.0.1 255.255.255.255'. Yeah, that's probably the path of least resistance. Note that the comments and possibly the SGML docs need to be adjusted to match, however, so it's not quite a one-liner. I think the SGML is fine. Here's a patch for the sample file. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 7.4.3 8.0.0beta1 + Solaris 9: default pg_hba.conf
Bruce Momjian wrote:
Added to open items:
* Fix Solaris for single-host netmasks in pg_hba.conf, use CIDR?
At this stage of the game I would just change pg_hba.conf.sample to use
'127.0.0.1/32' instead of '127.0.0.1 255.255.255.255'. No need for a
Solaris-specific fix for the default setup if we do that, and I don't
have time right now to do what I suggested below.
cheers
andrew
---
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Seems unlikely. I suppose you could argue that we shouldn't be using
getaddrinfo on the netmask field at all; there's certainly not any value
in doing a DNS lookup on it, for instance. Maybe we should go back to
using plain ol' inet_aton for it? (Nah, won't handle IPv6...)
We could do it if we tested the addr.ai_family first, and only did it in
the IPv4 case. I agree calling getaddrinfo is overkill for masks.
Huh? The reason we're using getaddrinfo in the first place is we don't
*know* whether we've got an IPv4 or IPv6 string ...
We know the address family - in fact we pass it to SockAddr_cidr_mask().
It's only the family of the mask that we don't know. But they had better
be the same, of course. See hba.c around line 753:
if (cidr_slash)
{
if (SockAddr_cidr_mask(mask, cidr_slash + 1,
addr.ss_family) 0)
goto hba_syntax;
}
else
{
/* Read the mask field. */
line_item = lnext(line_item);
if (!line_item)
goto hba_syntax;
token = lfirst(line_item);
ret = getaddrinfo_all(token, NULL, hints, gai_result);
cheers
andrew
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] 7.4.3 8.0.0beta1 + Solaris 9: default pg_hba.conf breaks
Andrew Dunstan [EMAIL PROTECTED] writes: At this stage of the game I would just change pg_hba.conf.sample to use '127.0.0.1/32' instead of '127.0.0.1 255.255.255.255'. Yeah, that's probably the path of least resistance. Note that the comments and possibly the SGML docs need to be adjusted to match, however, so it's not quite a one-liner. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 7.4.3 8.0.0beta1 + Solaris 9: default pg_hba.conf
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: At this stage of the game I would just change pg_hba.conf.sample to use '127.0.0.1/32' instead of '127.0.0.1 255.255.255.255'. Yeah, that's probably the path of least resistance. Note that the comments and possibly the SGML docs need to be adjusted to match, however, so it's not quite a one-liner. I think the SGML is fine. Here's a patch for the sample file. cheers andrew Index: src/backend/libpq/pg_hba.conf.sample === RCS file: /projects/cvsroot/pgsql-server/src/backend/libpq/pg_hba.conf.sample,v retrieving revision 1.49 diff -c -r1.49 pg_hba.conf.sample *** src/backend/libpq/pg_hba.conf.sample 1 Aug 2004 05:58:35 - 1.49 --- src/backend/libpq/pg_hba.conf.sample 19 Aug 2004 17:30:56 - *** *** 35,40 --- 35,43 # encrypted passwords. OPTION is the ident map or the name of the PAM # service. # + # Note: On some Solaris systems, an IP-MASK of 255.255.255.255 is known not to work. + # The corresponding CIDR-MASK of /32 does work. + # # Database and user names containing spaces, commas, quotes and other special # characters can be quoted. Quoting one of the keywords all, sameuser or # samegroup makes the name lose its special character, and just match a *** *** 49,56 # -- # # If you want to allow non-local connections, you need to add more ! # host records. Also, remember TCP/IP connections are only enabled ! # if you enable tcpip_socket in postgresql.conf. @authcomment@ --- 52,61 # -- # # If you want to allow non-local connections, you need to add more ! # host records. In that case you will also need to make PostgreSQL listen ! # on a non-local interface via the listen_addresses configuration parameter, or ! # the -i or -h command line switches. ! # @authcomment@ *** *** 58,63 local all all @authmethod@ # IPv4-style local connections: ! hostall all 127.0.0.1 255.255.255.255 @authmethod@ # IPv6-style local connections: hostall all ::1/128 @authmethod@ --- 63,68 local all all @authmethod@ # IPv4-style local connections: ! hostall all 127.0.0.1/32@authmethod@ # IPv6-style local connections: hostall all ::1/128 @authmethod@ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.4.3 8.0.0beta1 + Solaris 9: default pg_hba.conf breaks
Oliver Jowett [EMAIL PROTECTED] writes: Since the default config now allows TCP/IP connections from localhost, maybe we should tweak the default pg_hba.conf to work around this problem? (e.g. use the /32 syntax which works ok) Maybe we should press Sun to fix their bugs? Until M$, Solaris was the top of the list of platforms with known bugs that adversely affected Postgres; many of them bugs that were well known through multiple Solaris releases. We just last week worked around a Solaris bug that was publicly reported in 1995, for crissakes. For me, Solaris would be the second-from-last platform choice. If they want to get out of the cellar, they are going to have to work harder. Not expect me to work around more and more of their bugs. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.4.3 8.0.0beta1 + Solaris 9: default pg_hba.conf
Tom Lane wrote: Oliver Jowett [EMAIL PROTECTED] writes: Since the default config now allows TCP/IP connections from localhost, maybe we should tweak the default pg_hba.conf to work around this problem? (e.g. use the /32 syntax which works ok) Maybe we should press Sun to fix their bugs? Well, I can't argue with that. (it must be said that the solaris 9 install I am using is pretty out of date -- this problem may well be fixed by a later solaris patch) For me, Solaris would be the second-from-last platform choice. If they want to get out of the cellar, they are going to have to work harder. Not expect me to work around more and more of their bugs. I'm happy to put together the patch if you like. If it's not in the official codebase, I'll end up applying a patch when building our local packages anyway.. -O ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 7.4.3 8.0.0beta1 + Solaris 9: default pg_hba.conf breaks
Tom Lane wrote: Oliver Jowett [EMAIL PROTECTED] writes: Since the default config now allows TCP/IP connections from localhost, maybe we should tweak the default pg_hba.conf to work around this problem? (e.g. use the /32 syntax which works ok) Maybe we should press Sun to fix their bugs? Until M$, Solaris was the top of the list of platforms with known bugs that adversely affected Postgres; many of them bugs that were well known through multiple Solaris releases. We just last week worked around a Solaris bug that was publicly reported in 1995, for crissakes. For me, Solaris would be the second-from-last platform choice. If they want to get out of the cellar, they are going to have to work harder. Not expect me to work around more and more of their bugs. Agreed, but from a clarity perspective, are we better moving to the CIDR format for hostnames in pg_hba.conf anyway? I know CIDR is for networks, not hosts though. Also, I think we would accept a patch that modified pg_hba.conf for Solaris only that made this change. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.4.3 8.0.0beta1 + Solaris 9: default pg_hba.conf breaks
Bruce Momjian [EMAIL PROTECTED] writes: Agreed, but from a clarity perspective, are we better moving to the CIDR format for hostnames in pg_hba.conf anyway? Possibly --- it'd be easier to sell on that argument anyway ;-) Also, I think we would accept a patch that modified pg_hba.conf for Solaris only that made this change. That seems like the worst of all possible worlds. Difficult to do *and* confusing for users, since on Solaris the sample file would no longer match the documentation. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.4.3 8.0.0beta1 + Solaris 9: default pg_hba.conf breaks
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Agreed, but from a clarity perspective, are we better moving to the CIDR format for hostnames in pg_hba.conf anyway? Possibly --- it'd be easier to sell on that argument anyway ;-) Also, I think we would accept a patch that modified pg_hba.conf for Solaris only that made this change. That seems like the worst of all possible worlds. Difficult to do *and* confusing for users, since on Solaris the sample file would no longer match the documentation. True, but at least it would work. Are they saying the masks don't work at all? Why haven't we heard this before? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.4.3 8.0.0beta1 + Solaris 9: default pg_hba.conf breaks
Bruce Momjian [EMAIL PROTECTED] writes: True, but at least it would work. Are they saying the masks don't work at all? Why haven't we heard this before? The specific case of mask = all ones has got a problem (and I think there are some other conditions involved too). We have heard reports of this before, IIRC. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.4.3 8.0.0beta1 + Solaris 9: default pg_hba.conf
Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Agreed, but from a clarity perspective, are we better moving to the CIDR format for hostnames in pg_hba.conf anyway? Possibly --- it'd be easier to sell on that argument anyway ;-) s/hostnames/netmasks/ +1 vote. They are whole lot easier to understand anyway. We already did it for the IPv6 addr, and you thought it so nice you put it in the release notes :-) Also, I think we would accept a patch that modified pg_hba.conf for Solaris only that made this change. That seems like the worst of all possible worlds. Difficult to do *and* confusing for users, since on Solaris the sample file would no longer match the documentation. True, but at least it would work. Are they saying the masks don't work at all? Why haven't we heard this before? I thought the report was that *only* 255.255.255.255 failed. The question is why? And would changing the hints passed to getaddrinfo_all improve matters (e.g. by filling in the ai_family with the value from the addr structure we already have)? cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] 7.4.3 8.0.0beta1 + Solaris 9: default pg_hba.conf breaks
Andrew Dunstan [EMAIL PROTECTED] writes: I thought the report was that *only* 255.255.255.255 failed. The question is why? The impression I got was that some internal subroutine of getaddrinfo had a broken error-handling convention (ie, return a numeric address value or -1 on error). And would changing the hints passed to getaddrinfo_all improve matters (e.g. by filling in the ai_family with the value from the addr structure we already have)? Seems unlikely. I suppose you could argue that we shouldn't be using getaddrinfo on the netmask field at all; there's certainly not any value in doing a DNS lookup on it, for instance. Maybe we should go back to using plain ol' inet_aton for it? (Nah, won't handle IPv6...) regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] 7.4.3 8.0.0beta1 + Solaris 9: default pg_hba.conf breaks
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I thought the report was that *only* 255.255.255.255 failed. The question is why? The impression I got was that some internal subroutine of getaddrinfo had a broken error-handling convention (ie, return a numeric address value or -1 on error). And would changing the hints passed to getaddrinfo_all improve matters (e.g. by filling in the ai_family with the value from the addr structure we already have)? Seems unlikely. I suppose you could argue that we shouldn't be using getaddrinfo on the netmask field at all; there's certainly not any value in doing a DNS lookup on it, for instance. Maybe we should go back to using plain ol' inet_aton for it? (Nah, won't handle IPv6...) Uh, we are passing 255.255.255.255 to getaddrinfo()? Why would we do that? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.4.3 8.0.0beta1 + Solaris 9: default pg_hba.conf
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I thought the report was that *only* 255.255.255.255 failed. The question is why? The impression I got was that some internal subroutine of getaddrinfo had a broken error-handling convention (ie, return a numeric address value or -1 on error). Aha! Pardon me while I giggle. And would changing the hints passed to getaddrinfo_all improve matters (e.g. by filling in the ai_family with the value from the addr structure we already have)? Seems unlikely. I suppose you could argue that we shouldn't be using getaddrinfo on the netmask field at all; there's certainly not any value in doing a DNS lookup on it, for instance. Maybe we should go back to using plain ol' inet_aton for it? (Nah, won't handle IPv6...) We could do it if we tested the addr.ai_family first, and only did it in the IPv4 case. I agree calling getaddrinfo is overkill for masks. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] 7.4.3 8.0.0beta1 + Solaris 9: default pg_hba.conf breaks
Andrew Dunstan [EMAIL PROTECTED] writes: Seems unlikely. I suppose you could argue that we shouldn't be using getaddrinfo on the netmask field at all; there's certainly not any value in doing a DNS lookup on it, for instance. Maybe we should go back to using plain ol' inet_aton for it? (Nah, won't handle IPv6...) We could do it if we tested the addr.ai_family first, and only did it in the IPv4 case. I agree calling getaddrinfo is overkill for masks. Huh? The reason we're using getaddrinfo in the first place is we don't *know* whether we've got an IPv4 or IPv6 string ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.4.3 8.0.0beta1 + Solaris 9: default pg_hba.conf
Bruce Momjian wrote: Uh, we are passing 255.255.255.255 to getaddrinfo()? Why would we do that? Any non-CIDR netmask is passed to getaddrinfo to turn it into a binary mask. see src/backend/libpq/hba.c For CIDR masks we make the binary version ourselves. cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] 7.4.3 8.0.0beta1 + Solaris 9: default pg_hba.conf
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Seems unlikely. I suppose you could argue that we shouldn't be using
getaddrinfo on the netmask field at all; there's certainly not any value
in doing a DNS lookup on it, for instance. Maybe we should go back to
using plain ol' inet_aton for it? (Nah, won't handle IPv6...)
We could do it if we tested the addr.ai_family first, and only did it in
the IPv4 case. I agree calling getaddrinfo is overkill for masks.
Huh? The reason we're using getaddrinfo in the first place is we don't
*know* whether we've got an IPv4 or IPv6 string ...
We know the address family - in fact we pass it to SockAddr_cidr_mask().
It's only the family of the mask that we don't know. But they had better
be the same, of course. See hba.c around line 753:
if (cidr_slash)
{
if (SockAddr_cidr_mask(mask, cidr_slash + 1,
addr.ss_family) 0)
goto hba_syntax;
}
else
{
/* Read the mask field. */
line_item = lnext(line_item);
if (!line_item)
goto hba_syntax;
token = lfirst(line_item);
ret = getaddrinfo_all(token, NULL, hints, gai_result);
cheers
andrew
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] 7.4.3 8.0.0beta1 + Solaris 9: default pg_hba.conf breaks
Added to open items:
* Fix Solaris for single-host netmasks in pg_hba.conf, use CIDR?
---
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Seems unlikely. I suppose you could argue that we shouldn't be using
getaddrinfo on the netmask field at all; there's certainly not any value
in doing a DNS lookup on it, for instance. Maybe we should go back to
using plain ol' inet_aton for it? (Nah, won't handle IPv6...)
We could do it if we tested the addr.ai_family first, and only did it in
the IPv4 case. I agree calling getaddrinfo is overkill for masks.
Huh? The reason we're using getaddrinfo in the first place is we don't
*know* whether we've got an IPv4 or IPv6 string ...
We know the address family - in fact we pass it to SockAddr_cidr_mask().
It's only the family of the mask that we don't know. But they had better
be the same, of course. See hba.c around line 753:
if (cidr_slash)
{
if (SockAddr_cidr_mask(mask, cidr_slash + 1,
addr.ss_family) 0)
goto hba_syntax;
}
else
{
/* Read the mask field. */
line_item = lnext(line_item);
if (!line_item)
goto hba_syntax;
token = lfirst(line_item);
ret = getaddrinfo_all(token, NULL, hints, gai_result);
cheers
andrew
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
