could not bind IPv4 socket: Permission denied - postgresql

I am trying to set up a new instance of PostgreSQL 9.6 on a machine. I have tested it on another machine and its working fine on that machine. But the same process is not working on new machine. Below are the steps I am using
created a new data directory with below command
/opt/rh/rh-postgresql96/root/bin/initdb -D /var/lib/pgsql/9.6/data/
created a service file /etc/systemd/system/rh-postgresql96-inst2.service with below content
.include /lib/systemd/system/rh-postgresql96-postgresql.service
[Service]
Environment=PGDATA=/var/lib/pgsql/9.6/data/
Environment=PGPORT=5433
User=postgres
Group=root
registered service using command systemctl enable rh-postgresql96-inst2
now using command systemctl start rh-postgresql96-inst2 to start service.
All these steps are working fine on one machine but not on the 2nd one.
I am getting below error while starting service on the 2nd machine
rh-postgresql96-inst2.service - PostgreSQL database server
Loaded: loaded (/etc/systemd/system/rh-postgresql96-inst2.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2018-06-18 09:59:01 UTC; 10s ago
Process: 7552 ExecStart=/opt/rh/rh-postgresql96/root/usr/libexec/postgresql-ctl start -D ${PGDATA} -s -w -t ${PGSTARTTIMEOUT} (code=exited, status=1/FAILURE)
Process: 7550 ExecStartPre=/opt/rh/rh-postgresql96/root/usr/libexec/postgresql-check-db-dir %N (code=exited, status=0/SUCCESS)
HINT: Is another postmaster already running on port 5433? If not, wait a few seconds and retry.
LOG: could not bind IPv4 socket: Permission denied
HINT: Is another postmaster already running on port 5433? If not, wait a few seconds and retry.
WARNING: could not create listen socket for "localhost"
FATAL: could not create any TCP/IP sockets
LOG: database system is shut down
systemd[1]: rh-postgresql96-inst2.service: control process exited, code=exited status=1
systemd[1]: Failed to start PostgreSQL database server.
systemd[1]: Unit rh-postgresql96-inst2.service entered failed state.
systemd[1]: rh-postgresql96-inst2.service failed.
However, I am able to start service using pg_ctl.
Also, I have checked with netstat, lsof command to check if any other postgresql instance is running on port 5433 but its not the case.
Infact i tried 5431, 5434 ports also but server is not starting up

Instead of turning of SELinux you should allow postgres to bind to port 5433 in SELinux.
There is a port parameter postgresql_port_t which by default has port 5432 and 9898.
semanage port -l | grep post
postgresql_port_t tcp 5433, 9898
What you could do is simply add port 5433 to this list.
semanage port -a -t postgresql_port_t 5433 -p tcp
semanage port -l | grep post
postgresql_port_t tcp 5433, 5432, 9898
After that you can start your postgres server listening on port 5433
systemctl enable rh-postgresql96-postgresql
systemctl start rh-postgresql96-postgresql
netstat -tulpn
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 2847/postgres
tcp 0 0 127.0.0.1:5433 0.0.0.0:* LISTEN 2775/postgres
There is also a handy tool called audit2allow to help debug selinux problems.
audit2allow -m whatiswrong < /var/log/audit/audit.log > /root/showme.te
The file showme.te show you why SELinux is not allowing the service to do what you need.
You should not turn off SELinux just because it's hard to understand or if you don't know how it works. Instead you should study it :)
I reccomend this lecture from the Red Hat Summit https://www.redhat.com/en/about/videos/summit-2018-security-enhanced-linux-mere-mortals

This issue was related to SELinux.
When I run command sestatus on both machines, output was a little bit different.
One server had Current mode: permissive and 2nd one had Current mode: enforcing.
So I changed the current mode to permissive on the 2nd machine using command setenforce 0.
and it resolved the permission related issue. Now I am able to start 2nd instance.

Related

Is it needed to use more than one computer for master slave replication?

I am trying to create master slave replication physically with postgresql11 in debian10. I got same errors from different linux dists so is it something related making the replication in same computer? Or something related with master-slave accounts ?
root#dlp:~# vi /etc/postgresql/11/main/postgresql.conf
listen_addresses = '*'
wal_level = replica
synchronous_standby_names = '*'
wal_keep_segments = 10
I configured the pg_hba.conf as follows:
#host replication all 127.0.0.1/32 md5
#host replication all ::1/128 md5
host replication rep_user 127.0.0.1/32 trust
host replication rep_user 10.0.0.30/32 trust
host replication rep_user 10.0.0.51/32 trust
After this segment:
#i didnt create new user as node1 i just used my root/postgres account for all the processes
root#node01:~# systemctl stop postgresql
root#node01:~# rm -rf /var/lib/postgresql/11/main/*
root#node01:~# su - postgres
postgres#node01:~$ pg_basebackup -R -h dlp.srv.world -U rep_user -D /var/lib/postgresql/11/main -P
I got the following error:
pg_basebackup: could not connect to server: could not connect to server: Connection refused
Is the server running on host "dlp.srv.world" (180.43.145.38) and accepting
TCP/IP connections on port 5432?
also in the root account postgres is working fine but i doest show that port 5432 listening?
netstat -nlt
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
tcp6 0 0 ::1:631 :::* LISTEN
when i check the status of "postgresql" is says active but when i type :
systemctl status postgresql#11-main
Dec 14 06:20:52 debian postgresql#11-main[6260]: Error: /usr/lib/postgresql/11/bin/pg_ctl /
Dec 14 06:20:52 debian postgresql#11-main[6260]: pg_ctl: directory "/var/lib/postgresql/11/
Dec 14 06:20:52 debian systemd[1]: postgresql#11-main.service: Can't open PID file /run/pos
Dec 14 06:20:52 debian systemd[1]: postgresql#11-main.service: Failed with result 'protocol
Dec 14 06:20:52 debian systemd[1]: Failed to start PostgreSQL Cluster 11-main.
i got that error.

Armitage 'Connection refused' error in new install of Kali Linux after full upgrade

I installed Kali Linux via VMware and did a full system upgrade:
apt-get update
apt-get upgrade
apt-get full-upgrade
As part of the upgrade postgresql upgraded from v11 to v12. I followed the instructions to finish this part of the upgrade:
pg_dropcluster 12 main --stop
pg_upgradecluster 11 main
pg_dropcluster 11 main
I start postgresql, initialize metasploit, and start Armitage:
/etc/init.d/postgresql start
msfdb init
armitage
The only console output appears unrelated:
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on
-Dswing.aatext=true
I do get the popup box with the connection information. I found that I get the "Unexpected end of file from server" if I use 'localhost' as the host, so - per their instructions - I change it to the external IP (in this case 192.168.9.134). I checked metasploit-framework/config/database.yml for
the port and login credentials.
After clicking 'Connect' with this information I get a connection window stating:
Connecting to 192.168.9.134:5432 Connection refused (Connection
refused)
There's also the progress bar that over time will completely fill up (unless I click 'Cancel'). After which nothing happens. As I run the command from the terminal I can see that the process is still running (I don't get my prompt back) but the window disappears and Armitage doesn't actually start. The log file, as verified by pg_lsclusters (/var/log/postgresql/postgresql-12-main.log) doesn't is actually empty.
The link I mentioned before suggests that the problem could either be not enough RAM (I set the VM to have 4gb and free -m shows):
total used free shared buff/cache available
Mem: 3964 803 2677 29 483 2787
Swap: 4093 0 4093
Or that the Metasploit RPC daemon never started (that window does come up the first time, but not subsequent times). I verified that it's running via msfdb status:
● postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; disabled; vendor preset: disabled)
Active: active (exited) since Fri 2020-02-07 16:06:52 EST; 19min ago
Process: 1753 ExecStart=/bin/true (code=exited, status=0/SUCCESS) Main PID: 1753 (code=exited, status=0/SUCCESS)
Feb 07 16:06:52 kali systemd1: Starting PostgreSQL RDBMS... Feb 07
16:06:52 kali systemd1: Started PostgreSQL RDBMS.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME postgres
1735 postgres 3u IPv6 32516 0t0 TCP localhost:5432 (LISTEN)
postgres 1735 postgres 4u IPv4 32517 0t0 TCP localhost:5432
(LISTEN)
UID PID PPID C STIME TTY STAT TIME CMD postgres 1735
1 0 16:06 ? Ss 0:00 /usr/lib/postgresql/12/bin/postgres -D
/var/lib/postgresql/12/main -c
config_file=/etc/postgresql/12/main/postgresql.conf
[+] Detected configuration file
(/usr/share/metasploit-framework/config/database.yml)
Also, running regular Metasploit appears to work fine (msfconsole) and loads without error (not sure if there's any output that would be helpful here). I don't use postgresql directly, so I haven't messed with any configuration nor do I have any other applications (that I'm aware of) that use it, so it should be a pretty clean setup (not to mention this is a fresh install of Kali Linux). I'm out of ideas for what to check next. An online search didn't seem to match this problem well. Any thoughts?
Armitage has been deprecated for some time now, as it has not been updated since 2015, and is (to some extent) incompatible with current versions of metasploit.
Although this may not fix your problem, I suggest not using software this much out of date.

Unable to start docker container, "docker ps -a" STATUS = Exited (1)

I'm trying to start a postgres instance as described in docker hub.
To do that, I ran the following command:
sudo docker run --name database -e POSTGRES_PASSWORD=supersecret -p 5432:5432 -d postgres
When I run docker ps it shows nothing, and when I run docker ps -a it shows:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
967ebe7efb74 postgres "docker-entrypoint.s…" 2 minutes ago Exited (1) 2 minutes ago database
Trying to docker start database also leads to STATUS Exited (1) as displayed above.
Here are the logs displayed by docker logs -f database:
PostgreSQL init process complete; ready for start up.
2019-09-10 14:08:26.941 UTC [1] LOG: could not create IPv6 socket for address "::": Permission denied
2019-09-10 14:08:26.941 UTC [1] LOG: could not create IPv4 socket for address "0.0.0.0": Permission denied
2019-09-10 14:08:26.941 UTC [1] WARNING: could not create listen socket for "*"
2019-09-10 14:08:26.941 UTC [1] FATAL: could not create any TCP/IP sockets
2019-09-10 14:08:26.941 UTC [1] LOG: database system is shut down
In my research on the internet to solve this problem, some people said that it could be something with my hosts file, but it seems fine as shown below.
127.0.0.1 localhost
127.0.1.1 user-PC
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
I tried to reinstall docker following the docker docs step-by-step tutorial, and I also did the post installation steps without success.
OS: Deepin GNU/Linux 15.11
Docker: Docker version 18.09.6, build 481bc77
Because you confirmed it, I write the comment as answer.
Problem is due to apparmor.
Try disabling it or, better, to configure the security profile

How can I get the Postgres port

I just installed Postgres newly and I try to check if its running and on what port, although I know what default port it normally has
these commands are not showing me the port.
service postgresql status
I get this
postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor prese
Active: active (exited) since Tue 2018-09-18 14:17:14 CEST; 22min ago
Process: 2632 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Main PID: 2632 (code=exited, status=0/SUCCESS)
Tasks: 0
Memory: 0B
CPU: 0
CGroup: /system.slice/postgresql.service
Sep 18 14:17:14 user-HP-Pavilion-TS-15-Notebook-PC systemd[1]: Starting PostgreS
Sep 18 14:17:14 user-HP-Pavilion-TS-15-Notebook-PC systemd[1]: Started PostgreSQ
Sep 18 14:39:19 user-HP-Pavilion-TS-15-Notebook-PC systemd[1]: Started PostgreSQ
And when I just try to simply check process and see what port it shows this after the command
sudo netstat -plunt |grep postgres
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 2592/postgres
tcp 0 0 127.0.0.1:9187 0.0.0.0:* LISTEN 1065/postgres_expor
How can I get the port to show and what is going on?
This answer on serverfault needs you to connect to the machine and no other packages or root user.
Just connect and run the command.
If you can connect to PostgreSQL from the original machine you can see what port it's listening on:
SHOW port;
First, find the “postmaster” process, the parent of all other PostgreSQL processes.
You can get it from the postmaster.pid file in the PostgreSQL data directory if the database is started.
Then you can get the port with lsof. Assuming the process ID is 23521, run
lsof -P -sTCP:LISTEN -i TCP -a -p 23521
That will show you the port where PostgreSQL is listening.

openldap fails to bind ldaps://127.0.0.1:636

Here is my testcase :
[root#192.168.121.130 ~$]slapd -d 1 -h ldaps://127.0.0.1:636
#(#) $OpenLDAP: slapd 2.4.23 (Apr 29 2013 07:47:08) $
mockbuild#c6b7.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd
ldap_pvt_gethostbyname_a: host=centos-6.3, r=0
daemon_init: listen on ldaps://127.0.0.1:636
daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldaps://127.0.0.1:636)
daemon: bind(7) failed errno=98 (Address already in use)
slap_open_listener: failed on ldaps://127.0.0.1:636
slapd stopped.
connections_destroy: nothing to destroy.
But if I change another port , such as 6361, it works.
My environment:
OS: centos 6.4 x86_64
OpenLDAP: 2.4.23 installed by yum
Any suggestion?
it seems that another service is already running on port 636:
daemon: bind(7) failed errno=98 (Address already in use)
you can try the following command to identify this service:
netstat -tulpn | grep ':636 ' | grep 'LISTEN'
Old post, but still ...
This error is also displayed when SELinux prevents slapd from starting. Personally I experienced this after manually copying data (/var/lib/ldap/) from another server, to this one. I had to restore the imported files to default SELinux security contexts:
restorecon -R /var/lib/ldap
And I see this doesn't apply to you, but this might also happen if you're attempting to bind slapd to a port out of the ordinary. Default on CentOS7, these are the allowed ports:
#semanage port -l | grep ldap
ldap_port_t tcp 389, 636, 3268, 7389
ldap_port_t udp 389, 636
Adding another one to the legal port range, could be done with semanage. (You might need to install the package policycoreutils-python.):
semanage port -a -t ldap_port_t -p tcp 10389
... if you wish to allow slapd to bind on TCP port 10389 in addition to the four listed above. After this, the previous result would look like:
# semanage port -l | grep ldap
ldap_port_t tcp 10389, 389, 636, 3268, 7389
ldap_port_t udp 389, 636