Can listen_addresses really be set to a list?
I have a VM with IP address 192.168.0.192 running postgreSQL.
If I specify
listen_addresses = '*'
then I can connect from another VM at 192.168.0.191 and from localhost.
But I can't seem to use a list to tell postgreSQL to use those two addresses. If I change listen_addresses to a list:
listen_addresses = '192.168.0.191, localhost'
then I can no longer connect from 192.168.0.191.
I notice that almost all examples on stackexchange set listen_addresses to '*'. Is this because the list form does not work?
postgresql
add a comment |
I have a VM with IP address 192.168.0.192 running postgreSQL.
If I specify
listen_addresses = '*'
then I can connect from another VM at 192.168.0.191 and from localhost.
But I can't seem to use a list to tell postgreSQL to use those two addresses. If I change listen_addresses to a list:
listen_addresses = '192.168.0.191, localhost'
then I can no longer connect from 192.168.0.191.
I notice that almost all examples on stackexchange set listen_addresses to '*'. Is this because the list form does not work?
postgresql
add a comment |
I have a VM with IP address 192.168.0.192 running postgreSQL.
If I specify
listen_addresses = '*'
then I can connect from another VM at 192.168.0.191 and from localhost.
But I can't seem to use a list to tell postgreSQL to use those two addresses. If I change listen_addresses to a list:
listen_addresses = '192.168.0.191, localhost'
then I can no longer connect from 192.168.0.191.
I notice that almost all examples on stackexchange set listen_addresses to '*'. Is this because the list form does not work?
postgresql
I have a VM with IP address 192.168.0.192 running postgreSQL.
If I specify
listen_addresses = '*'
then I can connect from another VM at 192.168.0.191 and from localhost.
But I can't seem to use a list to tell postgreSQL to use those two addresses. If I change listen_addresses to a list:
listen_addresses = '192.168.0.191, localhost'
then I can no longer connect from 192.168.0.191.
I notice that almost all examples on stackexchange set listen_addresses to '*'. Is this because the list form does not work?
postgresql
postgresql
asked Aug 20 '13 at 3:09
zaboutizabouti
233134
233134
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
Yes, listen_addresses
can be set to a list of addresses on the local host to bind to for listening.
In your example:
listen_addresses = '192.168.0.191, localhost'
If the local machine has IP 192.168.0.192
, you should specify that IP, not the remote host 192.168.0.191
IP. PostgreSQL cannot bind to the IP address of a remote host.
You're not saying "who is allowed to connect", you're saying "which interfaces should PostgreSQL accept connections on". The "who's allowed to connect" bit is next, and is configured in pg_hba.conf
.
So: Try '192.168.0.192, localhost'
. Or just *
, since you probably actually want to listen on all network interfaces.
1
It works. So is there any practical difference between the list and '*'?
– zabouti
Aug 20 '13 at 3:37
10
@zabouti Sure. If your server has (say) two external network interfaces, you can tell PostgreSQL to only bind on one of them, so it's not even possible to make a TCP connection to Pg on the other. It's mostly an extra level of security for a system that has multiple interfaces to different security domains. Quite handy in combination with VLANs, virtual switches, etc. The most common use is setting it tolocalhost
so that TCP/IP connections are not possible from any external network interface, only the loopback address.
– Craig Ringer
Aug 20 '13 at 4:03
1
@CraigRinger: a very good answer!
– francs
Feb 25 '14 at 5:27
@CraigRinger you should add those comments to your answer. That's very useful information.
– João Portela
Dec 18 '14 at 10:57
1
Yeah I think the comment might be even better than the answer. Rock on Craig!
– Darth Egregious
Oct 7 '15 at 18:58
|
show 1 more comment
I've found that instead of using localhost
it needs to be 127.0.0.1
if you're specifying any other addresses as well.
So in my case of listening on the Docker host IP address as well as localhost, but not the external IP, this doesn't work (I get a connection refused from inside my Docker containers):
listen_addresses = '172.17.0.1, localhost'
But this does:
listen_addresses = '172.17.0.1, 127.0.0.1'
add a comment |
where to find listen address in psql?
New contributor
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "182"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f48372%2fcan-listen-addresses-really-be-set-to-a-list%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Yes, listen_addresses
can be set to a list of addresses on the local host to bind to for listening.
In your example:
listen_addresses = '192.168.0.191, localhost'
If the local machine has IP 192.168.0.192
, you should specify that IP, not the remote host 192.168.0.191
IP. PostgreSQL cannot bind to the IP address of a remote host.
You're not saying "who is allowed to connect", you're saying "which interfaces should PostgreSQL accept connections on". The "who's allowed to connect" bit is next, and is configured in pg_hba.conf
.
So: Try '192.168.0.192, localhost'
. Or just *
, since you probably actually want to listen on all network interfaces.
1
It works. So is there any practical difference between the list and '*'?
– zabouti
Aug 20 '13 at 3:37
10
@zabouti Sure. If your server has (say) two external network interfaces, you can tell PostgreSQL to only bind on one of them, so it's not even possible to make a TCP connection to Pg on the other. It's mostly an extra level of security for a system that has multiple interfaces to different security domains. Quite handy in combination with VLANs, virtual switches, etc. The most common use is setting it tolocalhost
so that TCP/IP connections are not possible from any external network interface, only the loopback address.
– Craig Ringer
Aug 20 '13 at 4:03
1
@CraigRinger: a very good answer!
– francs
Feb 25 '14 at 5:27
@CraigRinger you should add those comments to your answer. That's very useful information.
– João Portela
Dec 18 '14 at 10:57
1
Yeah I think the comment might be even better than the answer. Rock on Craig!
– Darth Egregious
Oct 7 '15 at 18:58
|
show 1 more comment
Yes, listen_addresses
can be set to a list of addresses on the local host to bind to for listening.
In your example:
listen_addresses = '192.168.0.191, localhost'
If the local machine has IP 192.168.0.192
, you should specify that IP, not the remote host 192.168.0.191
IP. PostgreSQL cannot bind to the IP address of a remote host.
You're not saying "who is allowed to connect", you're saying "which interfaces should PostgreSQL accept connections on". The "who's allowed to connect" bit is next, and is configured in pg_hba.conf
.
So: Try '192.168.0.192, localhost'
. Or just *
, since you probably actually want to listen on all network interfaces.
1
It works. So is there any practical difference between the list and '*'?
– zabouti
Aug 20 '13 at 3:37
10
@zabouti Sure. If your server has (say) two external network interfaces, you can tell PostgreSQL to only bind on one of them, so it's not even possible to make a TCP connection to Pg on the other. It's mostly an extra level of security for a system that has multiple interfaces to different security domains. Quite handy in combination with VLANs, virtual switches, etc. The most common use is setting it tolocalhost
so that TCP/IP connections are not possible from any external network interface, only the loopback address.
– Craig Ringer
Aug 20 '13 at 4:03
1
@CraigRinger: a very good answer!
– francs
Feb 25 '14 at 5:27
@CraigRinger you should add those comments to your answer. That's very useful information.
– João Portela
Dec 18 '14 at 10:57
1
Yeah I think the comment might be even better than the answer. Rock on Craig!
– Darth Egregious
Oct 7 '15 at 18:58
|
show 1 more comment
Yes, listen_addresses
can be set to a list of addresses on the local host to bind to for listening.
In your example:
listen_addresses = '192.168.0.191, localhost'
If the local machine has IP 192.168.0.192
, you should specify that IP, not the remote host 192.168.0.191
IP. PostgreSQL cannot bind to the IP address of a remote host.
You're not saying "who is allowed to connect", you're saying "which interfaces should PostgreSQL accept connections on". The "who's allowed to connect" bit is next, and is configured in pg_hba.conf
.
So: Try '192.168.0.192, localhost'
. Or just *
, since you probably actually want to listen on all network interfaces.
Yes, listen_addresses
can be set to a list of addresses on the local host to bind to for listening.
In your example:
listen_addresses = '192.168.0.191, localhost'
If the local machine has IP 192.168.0.192
, you should specify that IP, not the remote host 192.168.0.191
IP. PostgreSQL cannot bind to the IP address of a remote host.
You're not saying "who is allowed to connect", you're saying "which interfaces should PostgreSQL accept connections on". The "who's allowed to connect" bit is next, and is configured in pg_hba.conf
.
So: Try '192.168.0.192, localhost'
. Or just *
, since you probably actually want to listen on all network interfaces.
edited May 25 '16 at 9:55
answered Aug 20 '13 at 3:19
Craig RingerCraig Ringer
39.7k190132
39.7k190132
1
It works. So is there any practical difference between the list and '*'?
– zabouti
Aug 20 '13 at 3:37
10
@zabouti Sure. If your server has (say) two external network interfaces, you can tell PostgreSQL to only bind on one of them, so it's not even possible to make a TCP connection to Pg on the other. It's mostly an extra level of security for a system that has multiple interfaces to different security domains. Quite handy in combination with VLANs, virtual switches, etc. The most common use is setting it tolocalhost
so that TCP/IP connections are not possible from any external network interface, only the loopback address.
– Craig Ringer
Aug 20 '13 at 4:03
1
@CraigRinger: a very good answer!
– francs
Feb 25 '14 at 5:27
@CraigRinger you should add those comments to your answer. That's very useful information.
– João Portela
Dec 18 '14 at 10:57
1
Yeah I think the comment might be even better than the answer. Rock on Craig!
– Darth Egregious
Oct 7 '15 at 18:58
|
show 1 more comment
1
It works. So is there any practical difference between the list and '*'?
– zabouti
Aug 20 '13 at 3:37
10
@zabouti Sure. If your server has (say) two external network interfaces, you can tell PostgreSQL to only bind on one of them, so it's not even possible to make a TCP connection to Pg on the other. It's mostly an extra level of security for a system that has multiple interfaces to different security domains. Quite handy in combination with VLANs, virtual switches, etc. The most common use is setting it tolocalhost
so that TCP/IP connections are not possible from any external network interface, only the loopback address.
– Craig Ringer
Aug 20 '13 at 4:03
1
@CraigRinger: a very good answer!
– francs
Feb 25 '14 at 5:27
@CraigRinger you should add those comments to your answer. That's very useful information.
– João Portela
Dec 18 '14 at 10:57
1
Yeah I think the comment might be even better than the answer. Rock on Craig!
– Darth Egregious
Oct 7 '15 at 18:58
1
1
It works. So is there any practical difference between the list and '*'?
– zabouti
Aug 20 '13 at 3:37
It works. So is there any practical difference between the list and '*'?
– zabouti
Aug 20 '13 at 3:37
10
10
@zabouti Sure. If your server has (say) two external network interfaces, you can tell PostgreSQL to only bind on one of them, so it's not even possible to make a TCP connection to Pg on the other. It's mostly an extra level of security for a system that has multiple interfaces to different security domains. Quite handy in combination with VLANs, virtual switches, etc. The most common use is setting it to
localhost
so that TCP/IP connections are not possible from any external network interface, only the loopback address.– Craig Ringer
Aug 20 '13 at 4:03
@zabouti Sure. If your server has (say) two external network interfaces, you can tell PostgreSQL to only bind on one of them, so it's not even possible to make a TCP connection to Pg on the other. It's mostly an extra level of security for a system that has multiple interfaces to different security domains. Quite handy in combination with VLANs, virtual switches, etc. The most common use is setting it to
localhost
so that TCP/IP connections are not possible from any external network interface, only the loopback address.– Craig Ringer
Aug 20 '13 at 4:03
1
1
@CraigRinger: a very good answer!
– francs
Feb 25 '14 at 5:27
@CraigRinger: a very good answer!
– francs
Feb 25 '14 at 5:27
@CraigRinger you should add those comments to your answer. That's very useful information.
– João Portela
Dec 18 '14 at 10:57
@CraigRinger you should add those comments to your answer. That's very useful information.
– João Portela
Dec 18 '14 at 10:57
1
1
Yeah I think the comment might be even better than the answer. Rock on Craig!
– Darth Egregious
Oct 7 '15 at 18:58
Yeah I think the comment might be even better than the answer. Rock on Craig!
– Darth Egregious
Oct 7 '15 at 18:58
|
show 1 more comment
I've found that instead of using localhost
it needs to be 127.0.0.1
if you're specifying any other addresses as well.
So in my case of listening on the Docker host IP address as well as localhost, but not the external IP, this doesn't work (I get a connection refused from inside my Docker containers):
listen_addresses = '172.17.0.1, localhost'
But this does:
listen_addresses = '172.17.0.1, 127.0.0.1'
add a comment |
I've found that instead of using localhost
it needs to be 127.0.0.1
if you're specifying any other addresses as well.
So in my case of listening on the Docker host IP address as well as localhost, but not the external IP, this doesn't work (I get a connection refused from inside my Docker containers):
listen_addresses = '172.17.0.1, localhost'
But this does:
listen_addresses = '172.17.0.1, 127.0.0.1'
add a comment |
I've found that instead of using localhost
it needs to be 127.0.0.1
if you're specifying any other addresses as well.
So in my case of listening on the Docker host IP address as well as localhost, but not the external IP, this doesn't work (I get a connection refused from inside my Docker containers):
listen_addresses = '172.17.0.1, localhost'
But this does:
listen_addresses = '172.17.0.1, 127.0.0.1'
I've found that instead of using localhost
it needs to be 127.0.0.1
if you're specifying any other addresses as well.
So in my case of listening on the Docker host IP address as well as localhost, but not the external IP, this doesn't work (I get a connection refused from inside my Docker containers):
listen_addresses = '172.17.0.1, localhost'
But this does:
listen_addresses = '172.17.0.1, 127.0.0.1'
answered Dec 16 '18 at 0:58
VirtualWolfVirtualWolf
112
112
add a comment |
add a comment |
where to find listen address in psql?
New contributor
add a comment |
where to find listen address in psql?
New contributor
add a comment |
where to find listen address in psql?
New contributor
where to find listen address in psql?
New contributor
New contributor
answered 6 mins ago
Deepak Kumar SinghDeepak Kumar Singh
1
1
New contributor
New contributor
add a comment |
add a comment |
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f48372%2fcan-listen-addresses-really-be-set-to-a-list%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown