I'm getting this error when attempting to setup a new server on pgAdmin4:
Unable to connect to server:
could not connect to server: Connection refused (0x0000274D/10061)
Is the server running on host "192.168.210.146" and accepting
TCP/IP connections on port 5432?
I have postgres 12.7 running on CentOS 8 inside a virtual box 6.1 VM which is running on my Windows 10 21H1 laptop. I can connect to the OS using putty and the CentOS web client just fine.
Here is some network info via the CentOS web client terminal:
# nmap localhost
Starting Nmap 7.70 ( https://nmap.org ) at 2021-07-14 16:59 PDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000014s latency).
Other addresses for localhost (not scanned): ::1
Not shown: 996 closed ports
PORT STATE SERVICE
22/tcp open ssh
111/tcp open rpcbind
5432/tcp open postgresql
9090/tcp open zeus-admin
Nmap done: 1 IP address (1 host up) scanned in 1.68 seconds
netstat -tlpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1/systemd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 954/sshd
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 972/postmaster
tcp 0 0 127.0.0.1:37753 0.0.0.0:* LISTEN 1620/cockpit-bridge
# firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: enp0s3
sources:
services: cockpit dhcpv6-client postgresql ssh
ports: 5432/tcp
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
#
# ifconfig
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.210.146 netmask 255.255.254.0 broadcast 192.168.211.255
inet6 fe80::a00:27ff:fecb:8d2d prefixlen 64 scopeid 0x20<link>
ether 08:00:27:cb:8d:2d txqueuelen 1000 (Ethernet)
RX packets 4704 bytes 512333 (500.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3757 bytes 2510585 (2.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 7252 bytes 2161674 (2.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 7252 bytes 2161674 (2.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
In the PgAdmin setup server screen I'm using the ip address listed above of 192.168.210.146, user postgres and its password, port 5432 and the database is set to postgres.
I get this same error trying to establish odbc and jdbc connections from my laptop but I'm not sure what in the postgres environment needs to be fixed.I did add 1 entry the pg_hba.conf file as shown below, but that didn't help:
# IPv4 local connections:
host all all 127.0.0.1/32 ident
host all all 192.168.210.146/32 trust #added;not helping
Is there another file or setting that needs to be fixed?
Thanks.
The solution was to first un-comment the listen_address entry in postgresql.conf and then set it to the necessary ip number. Everything connects just fine now. Thanks
Related
I installed three operating systems(let's say 3 hosts) in VMware, all with NAT mode. 3 hosts are named centos, centos 1,centos 2.(As the pic shows below)
3 hosts in VMware
The first host's IP address is 192.168.248.132, the second is 192.168.248.136, and we don't need to know third host's IP because it's not related to this issue.
I typed the command "ping 192.168.248.136", and the output on the screen is:
PING 192.168.248.136 (192.168.248.136) 56(84) bytes of data.
64 bytes from 192.168.248.136: icmp_seq=1 ttl=64 time=0.435 ms
64 bytes from 192.168.248.136: icmp_seq=2 ttl=64 time=0.313 ms
64 bytes from 192.168.248.136: icmp_seq=3 ttl=64 time=0.385 ms
This means ping command has succeeded and host no.2(whose IP addr is 192.168.248.136) has received ICMP and replied.
Meanwhile, I typed the command "tcpdump -i ens33" in host no.3. If everything had worked correctly, host no.3 would not have received any data between host no.1 and host no.2, because ICMP is neither broadcast nor multicast, so only host no.1 and 2 can send and receive. Also, host no.3's network interface is not promiscuous mode, so it can only receive it's own frame. The output from host no.3 below can show it is not promiscuous mode.
[root#localhost usr]# ifconfig
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.248.137 netmask 255.255.255.0 broadcast 192.168.248.255
inet6 fe80::b488:bc2c:3770:a95f prefixlen 64 scopeid 0x20<link>
ether 00:0c:29:0d:dc:86 txqueuelen 1000 (Ethernet)
RX packets 351081 bytes 512917768 (489.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 34947 bytes 2166260 (2.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
flag is 4163<UP,BROADCAST,RUNNING,MULTICAST>, "PROMISC" is not mentioned, so it is not promiscuous mode.
However, after I typed "tcpdump -i ens33" in host no.3, something appeared on the screen:
06:28:11.511233 IP 192.168.248.132 > 192.168.248.136: ICMP echo request, id 3137, seq 5, length 64
06:28:11.511503 IP 192.168.248.136 > 192.168.248.132: ICMP echo reply, id 3137, seq 5, length 64
Host no.3 received the dataflow between no.1 and 2, and this was supposed to be sent to no.2, but no.3 received it.
So here comes the question, why can host no.3 receive packet which was not supposed to be sent to it?
tcpdump by default activates "promiscuous mode" making it able to see anything on the network it is connected to (even if not explicitly sent to it).
the three hosts seem to be connected to a virtual switch that do not isolate the hosts from each other.
I have 2 RPis connected together with an ethernet cable. For the 1st RPi, the wifi is disabled, and it should get the internet connection from the 2nd RPi that is connected to the internet by wifi.
I am using the Network Manager (NM), and I also need that both RPis have static IPs on their eth0 interface:
RPi1 : 192.168.4.115/24 # The RPi that is not connected to wifi
RPi2 : 192.168.4.1/24 # The RPi that is connected to wifi
I configured the static IP of the RPi1 in /etc/dhcpcd.conf. For the RPi2, I used the NM when I configured the shared connection :
# On RPi2
nmcli connection add type ethernet ifname eth0 ipv4.method shared con-name local
nmcli connection modify local ipv4.addresses 192.168.4.1/24
nmcli connection up local
When I check the connection of the RPi2, I have the good IP, and when I ping 1.1.1.1 I have a reply:
pi#raspberrypi2:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.4.1 netmask 255.255.255.0 broadcast 192.168.4.255
inet6 fe80::514:af1e:da15:6f80 prefixlen 64 scopeid 0x20<link>
ether e4:5f:01:4c:5c:00 txqueuelen 1000 (Ethernet)
RX packets 105 bytes 20375 (19.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 178 bytes 22385 (21.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.11.16 netmask 255.255.255.0 broadcast 192.168.11.255
inet6 fe80::750f:5ec2:8158:fb80 prefixlen 64 scopeid 0x20<link>
ether e4:5f:01:4c:5c:01 txqueuelen 1000 (Ethernet)
RX packets 488 bytes 59706 (58.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 206 bytes 30178 (29.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
But on the first RPi, even if I have the good IP on eth0 (192.168.4.115), when I try a ping, I have connect: network is unreachable
So I don't know what is missing to achieve the sharing of the connection. And I don't know what I can check? Feel free to ask for any useful data, I don't know what can be useful.
The first RPi doesn't use the NM because I don't need it, the normal way of the RPi is enough.
I can connect to my DigitalOcean Ubuntu 20LTS VM instant that has PostgreSQL 14 installed without issue, but I'm trying to make it more secure with only specific IPs that can connect to the database.
I heard the way to do this is to modify the /etc/postgresql/14/main/postgresql.conf file.
When I have this line, I can connect to my database without issue.
listen_addresses='0.0.0.0'
However, if I modify this line with:
listen_addresses='123.123.123.123'
I get this DataGrip error message: [08001] Connection to 111.111.111.111:12345 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.
111.111.111.111:12345 is my (fake) VM's IP and port that I already set up.
123.123.123.123 is my (fake) computer's external IP that I get from here or here
Any suggestions? Is there a log I can search from that will give me a better understanding of what is going on?
Also to note, with listen_addresses='0.0.0.0', running ss -ptl gives an output of
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 4096 127.0.0.53%lo:domain 0.0.0.0:*
LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:*
LISTEN 0 244 0.0.0.0:12345 0.0.0.0:*
LISTEN 0 128 [::]:ssh [::]:*
with listen_addresses='123.123.123.123', running ss -ptl gives an output of
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 4096 127.0.0.53%lo:domain 0.0.0.0:*
LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:*
LISTEN 0 128 [::]:ssh [::]:*
Documentation that I used so far:
https://www.postgresql.org/docs/current/runtime-config-connection.html
https://www.postgresql.org/docs/current/auth-pg-hba-conf.html
Can Spark be configured so that instead of binding to address 127.0.1.1 for port 7077, can
instead be bound to 0.0.0.0 . In same way as port 8080 is bound :
netstat -pln
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.1.1:7077 0.0.0.0:* LISTEN 2864/java
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 2864/java
tcp 0 0 127.0.1.1:6066 0.0.0.0:* LISTEN 2864/java
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
udp 0 0 0.0.0.0:68 0.0.0.0:* -
udp 0 0 192.168.192.22:123 0.0.0.0:* -
udp 0 0 127.0.0.1:123 0.0.0.0:* -
udp 0 0 0.0.0.0:123 0.0.0.0:* -
udp 0 0 0.0.0.0:21415 0.0.0.0:* -
Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node PID/Program name Path
unix 2 [ ACC ] STREAM LISTENING 7195 - /var/run/dbus/system_bus_socket
unix 2 [ ACC ] SEQPACKET LISTENING 405 - /run/udev/control
Reason I'm asking this is that I'm unable to connect workers to master node and I think the issue is that the master ip is not discoverable.
Error when try to connect slave to master :
15/04/02 21:58:18 WARN Remoting: Tried to associate with unreachable remote address [akka.tcp://sparkMaster#raspberrypi:7077]. Address is now gated for 5000 ms, all messages to this address will be delivered to dead letters. Reason: Connection refused: raspberrypi/192.168.192.22:7077
15/04/02 21:58:18 INFO RemoteActorRefProvider$RemoteDeadLetterActorRef: Message [org.apache.spark.deploy.DeployMessages$RegisterWorker] from Actor[akka://sparkWorker/user/Worker#1677101765] to Actor[akka://sparkWorker/deadLetters] was not delivered. [10] dead letters encountered. This logging can be turned off or adjusted with configuration settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
In spark-env.sh you can set SPARK_MASTER_IP=<ip>.
A hostname would also work fine (via SPARK_STANDALONE_MASTER=<hostname>), just make sure the workers connect to exactly the same hostname as the master binds to (i.e. the spark:// address that is shown in Spark master UI).
Whenever I open some help within eclipse I get a page saying:
Server Error. The following error occurred: [code=CANT_CONNECT_LOOPBACK] Cannot connect due to potential loopback problems
I'm running Ubuntu 10.04.
Any ideas what this can be?
UPDATE
Some commands outputs (some private info replaced):
$ ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:xx:xx:xx:xx:xx
inet addr:123.12.123.235 Bcast:123.12.456.255 Mask:255.255.254.0
inet6 addr: fe80::xxx:eff:xxxx:xxxx/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1343040 errors:0 dropped:0 overruns:0 frame:0
TX packets:1133672 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:829265876 (829.2 MB) TX bytes:242912202 (242.9 MB)
Memory:f3200000-f3220000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:125 errors:0 dropped:0 overruns:0 frame:0
TX packets:125 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:15910 (15.9 KB) TX bytes:15910 (15.9 KB)
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
123.12.123.0 0.0.0.0 255.255.254.0 U 1 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 123.12.456.254 0.0.0.0 UG 0 0 0 eth0
$ sudo netstat -anp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 765/portmap
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 871/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1181/cupsd
tcp 0 0 0.0.0.0:52068 0.0.0.0:* LISTEN 786/rpc.statd
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 1186/mysqld
tcp 0 0 0.0.0.0:53709 0.0.0.0:* LISTEN -
tcp 0 0 123.12.123.235:755 123.12.5.48:2049 ESTABLISHED -
tcp 0 0 123.12.123.235:60793 123.12.5.129:8080 ESTABLISHED 2264/firefox-bin
tcp 0 0 123.12.123.235:57940 123.12.5.43:8080 ESTABLISHED 2264/firefox-bin
tcp 0 0 123.12.123.235:57928 123.12.5.43:8080 CLOSE_WAIT 2247/google-chrome
tcp 0 0 123.12.123.235:35767 123.12.5.129:8080 ESTABLISHED 2247/google-chrome
tcp 0 0 123.12.123.235:57930 123.12.5.43:8080 ESTABLISHED 2247/google-chrome
tcp 0 0 123.12.123.235:57931 123.12.5.43:8080 CLOSE_WAIT 2247/google-chrome
tcp6 0 0 :::80 :::* LISTEN 1278/apache2
tcp6 0 0 :::22 :::* LISTEN 871/sshd
tcp6 0 0 ::1:631 :::* LISTEN 1181/cupsd
tcp6 0 0 :::55934 :::* LISTEN 1956/eclipse
tcp6 0 0 :::5900 :::* LISTEN 1792/vino-server
udp 0 0 0.0.0.0:35631 0.0.0.0:* 912/avahi-daemon: r
udp 0 0 0.0.0.0:962 0.0.0.0:* 786/rpc.statd
udp 0 0 0.0.0.0:68 0.0.0.0:* 1575/dhclient
udp 0 0 0.0.0.0:46149 0.0.0.0:* -
udp 0 0 0.0.0.0:5353 0.0.0.0:* 912/avahi-daemon: r
udp 0 0 0.0.0.0:111 0.0.0.0:* 765/portmap
udp 0 0 0.0.0.0:36211 0.0.0.0:* 786/rpc.statd
udp 0 0 123.12.123.235:123 0.0.0.0:* 1689/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 1689/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 1689/ntpd
udp6 0 0 fe80::227:eff:fe07::123 :::* 1689/ntpd
udp6 0 0 ::1:123 :::* 1689/ntpd
udp6 0 0 :::123 :::* 1689/ntpd
Active UNIX domain sockets (servers and established) due to post size limit.
UPDATE 2
My proxy bypass settings:
I know this is a late answer, but I had the same problem and resolved it, so to tie up this one...
This is a combination of two bugs:
(i) Eclipse's internal help browser doesn't use the Eclipse proxy settings! See:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=318969
(and the bugs referenced in comment #7 therein)
(ii) Ubuntu's proxy support is horribly broken in certain subtle ways. See:
https://bugs.launchpad.net/ubuntu/+bug/300271
The fix/workaround is to manually set the no_proxy environment variable before running eclipse (as reported in the Eclipse #308035 bug referenced from the 318969 one) e.g.
export no_proxy=127.0.0.1,localhost
eclipse &
Help then launches correctly within Eclipse. Of course, once Eclipse is launched (thus running its own internal HTTP server), you can also access the local help manually from another browser (or, if within the 'can't access 127.0.0.1' screen, there's an icon at the top to launch in an external window --> default system browser).
This may well apply on other Linux distros using Gnome.
[Couldn't post the 308035 bug link because my low reputation means I can only post 2 hyperlinks :-( Getting excited at this privilege come 10 reputation points :-)]
Basically, this error means that Eclipse is failing to establish a TCP/IP connection to your localhost using 127.0.0.1 (Eclipse starts a server for the Help).
If you are using some specific proxy settings (either global at the OS level or local at the Eclipse level), double check that you are bypassing the proxy for localhost and 127.0.0.1.
If this doesn't help, try setting the hostname that help uses to localhost when starting eclipse (either on the command line or in the eclipse.ini):
eclipse -vmargs -Dserver_host=localhost
Eclipse help is actually an HTTP server.
This is probably a permissions problem with your installation of Eclipse.
I have no suggestions except to check the permissions on your Eclipse folder, or delete and reinstall Eclipse.
had the same problem recently installing and running Eclipse on 9.10. Found that the default settings for Eclipse were fine but 9.10 had no proxy bypass set for 127.0.0.1 in its system settings. Also had to install Apache2 via Synaptic. I installed Apache2, did not change any settings for Apache2 and then went System > Preferences > Network Proxy Preferences clicked on Ignored Hosts and added "127.0.0.1". Reset the Eclipse Network Preferences back to default, restarted Eclipse and help worked perfectly. Hope this works for others.
David, thanks for the netstat output; you'll notice that Eclipse is listening on an IPv6 port:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp6 0 0 :::55934 :::* LISTEN 1956/eclipse
Is your proxy configuration set to bypass both 127.0.0.1 and ::1?
Make sure your /etc/hosts file is properly done. Usually
if the line containing 127.0.0.1 has your host name remove it and just leave 'localhost'
if the opposite were true, try adding your hostname to it :)
such things happen because gnome is trying to match hostname and sockets to handle UI things. Might be worth asking on superuser..