Hi folks. I have a
I have a
postgresql that’s dedicated to serving this database. Its name is server_n.local. I have another machine that needs to talk to it, and its name is server_f_local.
firewall-cmd commands on server_n.local to poke a hole into its
firewall to add both the
service and the
$ sudo firewall-cmd --zone=public --permanent --add-service=postgresql # firewall service allowed
$ sudo firewall-cmd --zone=public --permanent --add-port 5432/tcp # firewall port allowed
So I check the ports from that machine:
[Sun Jul 10 20:48:23 user1@server_n ~/rfs] sudo nmap -sS -p 0-6500 localhost
Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-10 20:52 EDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000050s latency).
Other addresses for localhost (not scanned): ::1
Not shown: 6499 closed ports
PORT STATE SERVICE
22/tcp open ssh
5432/tcp open postgresql
Nmap done: 1 IP address (1 host up) scanned in 0.13 seconds
It shows that
port 5432 is open. But when I do the same for server_f.local, this is what I see:
Starting Nmap 7.70 ( https://nmap.org ) at 2022-07-10 20:54 EDT
Nmap scan report for server_n.local (192.168.1.23)
Host is up (0.00038s latency).
Not shown: 6499 filtered ports
PORT STATE SERVICE
22/tcp open ssh
5432/tcp closed postgresql
MAC Address: D0:50:99:87:7B:4A (ASRock Incorporation)
Nmap done: 1 IP address (1 host up) scanned in 40.46 seconds
As you can see, server_f.local shows that port to be closed. I have no idea why this is happening. I currently think I’ve poked a hole (both incoming and outgoing) on server_n.local, and it’s being seen by my workstation and server_f.local as being closed.
How can I fix this? I need my machines to talk to this
postgresql database, and the port somehow remains
closed. I’ve read that
iptables is better to use, and should I be using that instead? That app sounds confusing compared to
Further research shows that my server is listening on
[Sun Jul 10 21:51:05 root@server_n ~] sudo netstat -tunlp
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:22 0.0.0.0:* LISTEN 918/sshd: /usr/sbin
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 929/postmaster
tcp6 0 0 :::22 :::* LISTEN 918/sshd: /usr/sbin
tcp6 0 0 ::1:5432 :::* LISTEN 929/postmaster
udp 0 0 127.0.0.1:323 0.0.0.0:* 836/chronyd
udp6 0 0 ::1:323 :::* 836/chronyd
nc -lp 5432 in the past to achieve this. Seems I need to take that out and enter this:
nc -lp4 5432 --allow 192.168.1.24 but I’m guessing as I don’t know how to remove the first
nc is more for single communications and scripted type stuff, as opposed to a way of making sure a
port is constantly listening.
is this your third of fourth thread about this now?
There is no real iptables in Alma because kernel now has nftables.
It keeps changing. The only part of all this that’s giving me hassles is
AlmaLinux, so I’m asking.
As it turns out, I’ve learned
firewalld is a wrapper for both
nptables. Also, the
firewall stuff worked, but for some reason the
ports are not listening. I can tweak the
port open using
nc but that’s not a permanent solution. I know I’m missing something, and I have some feelers out.
You have been told in your other threads (about this same issue) that a “port” does not listen and firewall does not listen – process does. In your case the process must be ‘postmaster’, the process that
postgresql.service does start.
nc is not a solution, not even a temporary solution. The
nc is a totally different program that you can make listen to port ‘5432/tcp’, but when the nc process listens there, then the postmaster cannot – only one process can listen a specific port. Your psql clients cannot talk to nc, they must talk to postmaster.
What you are missing is the correct configuration of postgresql. (That is not Alma-specific; postgresql probably has same config on all platforms.)
OK, you’re confusing a couple of things. Not once did I say I was going to use any
postgres client through
nc. I was using
nc to see if I can get any communications, as
postgresql.conf was set up to listen on many ports. So the process was working for
localhost but not across the
LAN. Yes the conf file was set up for the whole
Second, that communications was turning off. I’m currently measuring that now.
listen_addresses to set which interfaces are listened. It could have
'*' when firewall and authentication limit access.
The authentication is in
pg_hba.conf. What did you add there?
postgresql.conf I spend a lot of time in. I had *, which originally broke all listening, then I broke it out to
IP4 options (0.0.0.0, localhost4, 192.168.1.23), and now back to *. As for
host all user1 192.168.1.4 255.255.255.0 trust
host all user1 192.168.1.24 255.255.255.0 md5
It seems to be working now, and still testing