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 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
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 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 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
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 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: > 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: > 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
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
