You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue: Multiple concurrent versions of Postgresql DB causes metasploit to not install/initialize it's database properly
Root cause
Postgres v10 and v12 were simultaneously installed and running on my system
OS Version
Ubuntu 20.04
Solution
Delete oldest version of postgres via apt remove postgresql-##
Full issue description/troubleshooting steps:
I encountered a bizarre and unique case where installing metasploit would always fail for me when trying to initialize the database.
For no apparent reason, msfdb init would fail during the msfdb initialization procedure, citing that "port 5432/5433" was in use and could not be bound according to the logs.
➜ ~ msfdb init
[?] Would you like to delete your existing data and configurations?: yes
====================================================================
Running the 'init' command for the database:
Found a database at /home/truedemon/.msf4/db, checking to see if it is started
Starting database at /home/truedemon/.msf4/db...failed
LOG: database system is shut down
[!] Your database may be corrupt. Try reinitializing.
====================================================================
====================================================================
Running the 'init' command for the webservice:
[?] Initial MSF web service account username? [truedemon]: ^CTraceback (most recent call last):
6: from msfdb:1094:in `<main>'
5: from msfdb:1094:in `each'
4: from msfdb:1097:in `block in <main>'
3: from msfdb:994:in `invoke_command'
2: from msfdb:473:in `init_web_service'
1: from msfdb:385:in `ask_value'
msfdb:385:in `gets': Interrupt
After deferring to the ~/.msf4/db/log, I understood that msfdb was trying to set up a socket on port 5433 to the local postgres database.
(Sorry I don't have the log output, as it got overwritten, but the principle log item that tipped me off was the "Cannot BIND IPv4 Port 5433")
After seeing that my /etc/postgresql/12/postgresql.conf was set up on port 5433 and that the process was running, I decided to just bump the database.yml port to 5433. This would result in the msfdb init command succeeding, but afterwards, msfconsole would complain that it could not connect to the database because the 'msf' user did not exist. This made no sense to me.
Upon investigation, I discovered the cause was due to having multiple versions of postgres installed (version 10 and 12 in my case).
Proposed solutions
Perhaps this is too edge-case for the omnibus installer/msfdb command, but it may be worth noting if multiple postgres databases are detected while running. There are multiple ways to do this, such as checking for multiple config folders under /etc/postgresql/ which appear as /etc/postgresql/## such as /etc/postgresql/10 and etc/postgresql/12
Another is to check netstat/ss output for multiple processes named postgresql and determining which binary is in use.
At the very least, I want to document this for future metasploit users in case this is encountered by someone else, because it was very frustrating to troubleshoot, and had prevented me from using Metasploit on my Ubuntu system for the better part of a month. It may be worth documenting in the msfdb init procedure that if it fails, users should verify that postgres is running on port 5432 and that there are not multiple databases running. Otherwise, you get some confusing problems connecting to a database that doesn't exist. :(
The text was updated successfully, but these errors were encountered:
Issue: Multiple concurrent versions of Postgresql DB causes metasploit to not install/initialize it's database properly
Root cause
Postgres v10 and v12 were simultaneously installed and running on my system
OS Version
Ubuntu 20.04
Solution
Delete oldest version of postgres via
apt remove postgresql-##
Full issue description/troubleshooting steps:
I encountered a bizarre and unique case where installing metasploit would always fail for me when trying to initialize the database.
For no apparent reason,
msfdb init
would fail during the msfdb initialization procedure, citing that "port 5432/5433" was in use and could not be bound according to the logs.After deferring to the
~/.msf4/db/log
, I understood that msfdb was trying to set up a socket on port 5433 to the local postgres database.(Sorry I don't have the log output, as it got overwritten, but the principle log item that tipped me off was the "Cannot BIND IPv4 Port 5433")
After seeing that my
/etc/postgresql/12/postgresql.conf
was set up on port 5433 and that the process was running, I decided to just bump the database.yml port to 5433. This would result in the msfdb init command succeeding, but afterwards,msfconsole
would complain that it could not connect to the database because the 'msf' user did not exist. This made no sense to me.Upon investigation, I discovered the cause was due to having multiple versions of postgres installed (version 10 and 12 in my case).
Proposed solutions
Perhaps this is too edge-case for the omnibus installer/msfdb command, but it may be worth noting if multiple postgres databases are detected while running. There are multiple ways to do this, such as checking for multiple config folders under
/etc/postgresql/
which appear as/etc/postgresql/##
such as/etc/postgresql/10
andetc/postgresql/12
Another is to check netstat/ss output for multiple processes named
postgresql
and determining which binary is in use.At the very least, I want to document this for future metasploit users in case this is encountered by someone else, because it was very frustrating to troubleshoot, and had prevented me from using Metasploit on my Ubuntu system for the better part of a month. It may be worth documenting in the
msfdb init
procedure that if it fails, users should verify that postgres is running on port 5432 and that there are not multiple databases running. Otherwise, you get some confusing problems connecting to a database that doesn't exist. :(The text was updated successfully, but these errors were encountered: