Re: [HACKERS] listening addresses
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I did wonder if we should treate localhost as a bit special and not rely on the resolver for it. I don't think so; we went in the other direction in 7.4 for pgstats. (It used to try to bind to 127.0.0.1 and now tries localhost.) So far I've not seen any evidence that makes me think that was a bad choice. A small problem with it was reported to me a couple of days ago - user had firewalled off all IP6 traffic. The stats collector happily bound and connected to the socket, but all the packets fell in the bit bucket. They found it quite hard to diagnose the problem. Possible solutions that occurred to me: . an initial hello-yes i'm here exchange to validate the address . a configurable stats collector address . fix the firewall (Doctor, it hurts when I move like this. - So, stop moving like that.) cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] listening addresses
Andrew Dunstan [EMAIL PROTECTED] writes: A small problem with it was reported to me a couple of days ago - user had firewalled off all IP6 traffic. The stats collector happily bound and connected to the socket, but all the packets fell in the bit bucket. They found it quite hard to diagnose the problem. Possible solutions that occurred to me: . an initial hello-yes i'm here exchange to validate the address That one seems reasonable to me. Seems like it would take just a few more lines of code in the loop that tries to find a working socket to check that we can send a byte and receive it. You'd have to be careful not to block if the socket is indeed not working ... also, is it safe to assume that a byte sent with send() is *immediately* ready to recv()? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] listening addresses
Tom Lane wrote: also, is it safe to assume that a byte sent with send() is *immediately* ready to recv()? If not presumably you could either sleep for a very small interval before the recv or select on the socket for a very small interval. Half a second should be ample, I would think. This doesn't strike me as a high priority item, but possibly worth putting on the TODO list? Or I could just include it when I get around to the rest of the listening address stuff we discussed earlier. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] listening addresses
Andrew, Tom: This will be a really nice feature for those of us with PG servers that participate in VPNs.Currently I'm blocking certain interfaces using pg_hba.conf but would prefer a listen address instead. Of course, the drawback to this is that confused DBAs will have their pg_hba.conf conflict with their postgresql.conf, and cut off all access to the DB. But I don't know how we can protect against that. Might I suggest that this default to 127.0.0.1 in postgresql.conf.sample? This is a reasonably safe default, and would allow us to use the same default for Windows as for other OSes. It would also eliminate about 15% of the questions I get on a weekly basis from PHP users. (uncomment the line tcpip_sockets ...). If I had time, I would also love to see setting the password for the postgres user become part of the initdb script. However, I can see that this wouldn't work with packages. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] listening addresses
Josh Berkus wrote: Andrew, Tom: This will be a really nice feature for those of us with PG servers that participate in VPNs.Currently I'm blocking certain interfaces using pg_hba.conf but would prefer a listen address instead. Of course, the drawback to this is that confused DBAs will have their pg_hba.conf conflict with their postgresql.conf, and cut off all access to the DB. But I don't know how we can protect against that. Might I suggest that this default to 127.0.0.1 in postgresql.conf.sample? This is a reasonably safe default, and would allow us to use the same default for Windows as for other OSes. It would also eliminate about 15% of the questions I get on a weekly basis from PHP users. (uncomment the line tcpip_sockets ...). If I had time, I would also love to see setting the password for the postgres user become part of the initdb script. However, I can see that this wouldn't work with packages. Why couldn't we do something where we ask for a password only if stdin is from a terminal? -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] listening addresses
Josh Berkus [EMAIL PROTECTED] writes: Might I suggest that this default to 127.0.0.1 in postgresql.conf.sample? No, the default should be localhost. Your thinking is too IPv4-centric. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] listening addresses
Tom, No, the default should be localhost. Your thinking is too IPv4-centric. Good point. My clients are all years away from implementing Ipv6, so I tend to forget about it. -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] listening addresses
I wrote: Josh Berkus wrote: If I had time, I would also love to see setting the password for the postgres user become part of the initdb script. However, I can see that this wouldn't work with packages. Orthogonal problem. BTW, initdb is no longer a script - some idiot rewrote it in C :-) And it does have a switch for setting the superuser password: -W --pwprompt Makes initdb prompt for a password to give the database superuser. If you don't plan on using password authentication, this is not important. Otherwise you won't be able to use password authentication until you have a password set up. 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] listening addresses
Idiot is such a strong word, don't you think? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Dunstan Sent: Tuesday, March 16, 2004 7:26 AM To: Postgresql Hackers Subject: Re: [HACKERS] listening addresses I wrote: Josh Berkus wrote: If I had time, I would also love to see setting the password for the postgres user become part of the initdb script. However, I can see that this wouldn't work with packages. Orthogonal problem. BTW, initdb is no longer a script - some idiot rewrote it in C :-) And it does have a switch for setting the superuser password: -W --pwprompt Makes initdb prompt for a password to give the database superuser. If you don't plan on using password authentication, this is not important. Otherwise you won't be able to use password authentication until you have a password set up. 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] listening addresses
Andrew Dunstan [EMAIL PROTECTED] writes: The intention is to make localhost the default. That should translate to 127.0.0.1 and ::1 (if they have ipv6 on). Of course, if they have a broken resolver things might get sticky, but that is true now anyway. Just to be clear: right now, if localhost doesn't resolve then the stats collector will not start, but this doesn't prevent use of the database. It might be a good idea to ensure that the same is still true after making this change; that is, invalid entries in listen_addresses should only provoke warnings and not refusal to start (assuming that we are able to find at least one valid socket to listen to, of course). I believe that right now, any bad entry in virtual_host causes the postmaster to error out. That's defensible from one point of view but on balance I think it's overly paranoid. Any other opinions out there? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] listening addresses
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: The intention is to make localhost the default. That should translate to 127.0.0.1 and ::1 (if they have ipv6 on). Of course, if they have a broken resolver things might get sticky, but that is true now anyway. Just to be clear: right now, if localhost doesn't resolve then the stats collector will not start, but this doesn't prevent use of the database. It might be a good idea to ensure that the same is still true after making this change; that is, invalid entries in listen_addresses should only provoke warnings and not refusal to start (assuming that we are able to find at least one valid socket to listen to, of course). I believe that right now, any bad entry in virtual_host causes the postmaster to error out. That's defensible from one point of view but on balance I think it's overly paranoid. Any other opinions out there? Makes sense - we are not giving anything away but *not* listening to something. I did wonder if we should treate localhost as a bit special and not rely on the resolver for it. cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] listening addresses
Andrew Dunstan [EMAIL PROTECTED] writes: I did wonder if we should treate localhost as a bit special and not rely on the resolver for it. I don't think so; we went in the other direction in 7.4 for pgstats. (It used to try to bind to 127.0.0.1 and now tries localhost.) So far I've not seen any evidence that makes me think that was a bad choice. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] listening addresses
Tom Lane wrote: Josh Berkus [EMAIL PROTECTED] writes: Might I suggest that this default to 127.0.0.1 in postgresql.conf.sample? No, the default should be localhost. Your thinking is too IPv4-centric. FYI, once we default to listening on localhost, we need to warn folks who are using socket permission to control access that they have to turn off localhost. That needs to be mentioned in the release notes, and in the SGML docs that talk about socket permissions. -- 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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] listening addresses
Bruce Momjian [EMAIL PROTECTED] writes: FYI, once we default to listening on localhost, we need to warn folks who are using socket permission to control access that they have to turn off localhost. That needs to be mentioned in the release notes, and in the SGML docs that talk about socket permissions. True. I don't see this as a big problem, since use of socket permissions requires some nondefault settings in postgresql.conf anyway (IIRC). Adjusting listen_addresses too shouldn't be a big deal. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] listening addresses
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: FYI, once we default to listening on localhost, we need to warn folks who are using socket permission to control access that they have to turn off localhost. That needs to be mentioned in the release notes, and in the SGML docs that talk about socket permissions. True. I don't see this as a big problem, since use of socket permissions requires some nondefault settings in postgresql.conf anyway (IIRC). Adjusting listen_addresses too shouldn't be a big deal. No, it isn't a problem. I just wanted to mention is so we remember to address it. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] listening addresses
Andrew Dunstan [EMAIL PROTECTED] writes: This slipped off my radar. I have just spent a little while thinking about it. How about this: we replace tcpip_socket and virtual_host with a new var called listen_addresses, which can have values of local, all, or a list of addresses? The default would be local and -i would correspond to all. No objection here. You could also allow none (or maybe that falls out of the list case by writing an empty list), with the understanding that none is a useless setting on Windows or any other platform that doesn't support Unix sockets. Yes, I know it's not backwards compatible, but we just went through that argument with log_line_prefix ;-) I think it's the same argument: neither of these variables are likely to be touched by application code, only by config file entries; so we need not feel compelled to provide backwards-compatibility options. Actually, if we wanted to go the whole hog with virtual hosting we'd allow per-address port specification, like apache does, but maybe that's something to be left for another day ;-) Yeah, I don't think that's worth the trouble. It would open up a bunch of definitional issues (like which port number do we use as the seed for the shared memory key), without actually buying much useful functionality. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
