I have an issue with establishing a remote connection to MongoDB running on a VPS. I have followed instructions on editing the mongod.conf to bind my IP.
The network section looks like this:
# network interfaces
net:
port: 27017
bindIp: 127.0.0.1,xx.xx.xxx.xxx
The latter IP is my local machine which I am trying to access MongoDB on using Compass.
I have also tried surrounding the list in [], but it does not work. I am restarting the mongo service after each change like so:
sudo systemctl restart mongod
When I try to run mongo after adding the new comma-separated IP to the bindIp I receive the following error.
MongoDB shell version v4.4.9
connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb
Error: couldn't connect to server 127.0.0.1:27017, connection attempt failed: SocketException: Error connecting to 127.0.0.1:27017 :: caused by :: Connection refused :
connect#src/mongo/shell/mongo.js:374:17
#(connect):2:6
exception: connect failed
exiting with code 1
When I edit the mongo.conf to remove the second IP, mongo works and I can use the shell.
I have also created a new user in the MongoDB admin to use as credentials in Compass which I am using to try to connect in Compass.
This is what the user looks like in the admin system.users collection.
{
"_id" : "admin.newAdmin",
"userId" : UUID("9b5c9a51-de6b-4e55-a2bc-3ae92d89993c"),
"user" : "newAdmin",
"db" : "admin",
"credentials" : { ... },
"roles" : [
{
"role" : "userAdminAnyDatabase",
"db" : "admin"
},
{
"role" : "readWriteAnyDatabase",
"db" : "admin"
}
]
}
The connection string in Compass:
mongodb://username:password#<vps-ip>:27017/?authSource=admin&readPreference=primary&ssl=false
I have seen that replacing bindIp with 0.0.0.0 works, but I am not comfortable with that from a security point of view.
If anyone can help with a solution to securely and easily establishing a remote connection I would much appreciate it.
bindIp is a list of network interfaces to listen on mongodb server, not a list of client IPs.
Assuming mongodb is running on *nix system, list available interfaces in terminal:
ifconfig
or
ip -c a
depending on distributive
there is at least 1 virtual interface "lo" inet 127.0.0.1 - the local loop, and at least 1 physical interface associated with the network card - something like "eth0", "wifi0", etc. Numbers may differ, as well as number of interfaces.
Get the IP from inet property and add it to mongodb config.
Let me stress, bindIp does not limit who can connect to mongo, only what networks mongo listens on, so if there are only 2 interfaces - lo and eth0 there is no difference between listing both of them in the config, or using 0.0.0.0.
If you want to limit traffic from specific client IP - use system firewall.
Related
I used pg_isready -h localhost which gives output as localhost:5432 - accepting connections
But when i used my host-ip instead of localhost ,it gives output as
pg_isready -h 18.191.7.185
output is 18.191.7.185:5432 - no response
My localhost isn't my ip-address?
No, it isn't. Verify with
ping localhost
which will show you the IP address that localhost resolves to.
The “loopback interface” is a special network interface that only contains your computer.
The cause of the problem is probably that the PostgreSQL parameter listen_addresses, which specifies the network interfaces on which PostgreSQL is listening, is set to the default value localhost.
Change the value to * and restart PostgreSQL, and it should work.
A second possibility is that you have restrictive firewall settings on your machine. Actually, reading your question again, that is probably your problem, since you are receiving no response rather that an error saying that nothing is listening on that port.
I am in the process of setting up a remote PostgreSQL database. The server is running CentOS 7 and PostgreSQL-9.5. Currently, I am testing whether users can query the database. To this end, I have the following:
import psycopg2
host = 'server1'
dbname = 'test_db'
user = 'test-user'
sslcert = 'test-db.crt'
sslmode = 'verify-full'
sslkey = 'test-db.key'
dsn = 'host={0} dbname={1} user={2} sslcert={3} sslmode={4} sslkey={5}'.format(host, dbname, user, sslcert, sslmode, sslkey)
conn = psycopg2.connect(dsn)
The connection times out with the following error:
psycopg2.OperationalError: could not connect to server: Connection timed out (0x0000274C/10060)
Is the server running on host "server1" (xx.xx.xx.xx) and accepting
TCP/IP connections on port 5432?
I have tried several things (given below). I'm trying to pin down on which side the problem exists: the Python end or the database configuration:
Is the Python syntax correct?
Where can I find documentation concerning the DSN arguments, such as sslmode, sslcert, and sslkey?
Is there a different package better suited for this kind of connection?
What other questions should I be asking?
I have checked the following:
'server1' was entered correctly and the IP address returned by Python corresponds
All other arguments are spelled correctly and refer to the correct object
Postgres is currently running (service postgres-9.5 status shows "active")
Postgres is listening on port 5432 (netstat -na | grep tcp shows "LISTEN" on port 5432)
SSL is running for my table (psql -U username -W -d test-db -h host returns SSL connection (protocol: TLSAv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
user=test-user has been added to postgres as a Superuser
My understanding is that psycopg2 is the appropriate package to use nowadays. I have scoured the documentation and don't find much information regarding SSL connections. I found this SO post which talks about SSL connections using psycog2, but I can't match some of the syntax to the documentation.
In the Python script, I have tried the following in all 4 combinations:
Use sslmode='require'
Use absolute paths to test-db.crt and test-db.key
It appears that you have presented yourself with a False Dilemma. The problem does not lie solely between Python and the database configuration. There exist other entities in between which may cause a disconnect.
Is the Python syntax correct?
Yes. The syntax is described in the psycopg2.connect() documentation. It has the form:
psycopg2.connect(dsn=None, connection_factory=None, cursor_factory=None, async=False, **kwargs)
where the DSN (Data Source Name) can be given as a single string or as separate arguments:
conn = psycopg2.connect(dsn="dbname=test user=postgres password=secret")
conn = psycopg2.connect(dbname="test", user="postgres", password="secret")
Where can I find documentation concerning the DSN arguments, such as sslmode, sslcert, and sslkey?
Note that as DSN arguments, they are not part of the psycopg2 module. They are defined by the database, in this case Postgres. They can be found in the chapter on Database Connection Control Functions, under the Parameter Key Words section.
What other questions should I be asking?
Perhaps,
Is there anything between the host (the PostgresSQL server) and the client (the local Python instance) which could prevent communication?
One answer to this would be "the firewall." This turned out to be the problem. Postgres was listening and Python was reaching out. But the door was closed.
I've failed to set up postgreSQL to work with my Ruby-on-Rails project for the past week. I've tried to uninstall and reinstall, postgreSQL, twice now.But when I try to launch postgreSQL I keep getting the error below:
could not connect to server: Connection refused (0x0000274D/10061)
Is the server running on host "localhost" (::1) and
accepting TCP/IP connections on port 5432?
could not connect to server: Connection refused (0x0000274D/10061)
Is the server running on host "localhost" (127.0.0.1) and
accepting TCP/IP connections on port 5432?"
I've looked at many online resources, including stackoverflow and none seem helpful.The key parts of my pg_hba.conf file looks like this:
# TYPE DATABASE USER ADDRESS METHOD
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
#host replication postgres 127.0.0.1/32 md5
#host replication postgres ::1/128 md5
And the key part of my postgresql.conf file is as follows:
listen_addresses = '*' # what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost'; use '*' for all
# (change requires restart)
port = 5432 # (change requires restart)
max_connections = 100 # (change requires restart)
#superuser_reserved_connections = 3 # (change requires restart)
#unix_socket_directories = '' # comma-separated list of directories
# (change requires restart)
#unix_socket_group = '' # (change requires restart)
#unix_socket_permissions = 0777 # begin with 0 to use octal notation
Most of the suggestions, I've seen so far, were based on those two files. (For my case, they were already configured correctly). I also tried disabling the firewall and restarting postgreSQL but it didn't help. Does anyone have any suggestions for me? Thanks!
Got the same issue while settings up PostgreSQL 9.6.16 to work with Python/Django, but this is purely a database issue.
The solution lies in the error: In fact, I found this error mentioned within the official PostgreSQL documentation thus it's a common error.
And here is how I resolved this issue:
Always first start the postgres database server, use postgres or the wrapper program pg_ctl.I used the command, below, on windows 10.Remember, whatever comes after -D should be the path to where you installed PostgreSQL, to the data folder, which holds the pg_hba.conf and postgresql.conf files.
> pg_ctl start -D "C:/Program Files/PostgreSQL/9.6/data"
If that runs well, you are ready to access the database server.Open another cmd shell, and type the command below.Remember the password you entered while installing PostgreSQL?Enter that password when asked Password for user postgres:
> psql -U postgres
Once done, you can now go ahead to CREATE ROLE and CREATE DATABASE accordingly.
I am currently developing a website with a virtual server based on Vagrant. Before that I always used my NAS-webserver to develop my sites.
I want to keep using my database on the NAS cause it's easy to handle through phpMyAdmin that is installed as an app on the NAS.
When ssh'ed into my virtualbox I can ping to the internal ip from my NAS, being 192.168.0.10. Making a database connection to it, does not work.
Usually I take static ip for my VirtualBox that does not belong to the range of my internal network, e.g. 192.168.33.23. I tried to change this to an ip that is in the range but then I get an error saying:
The specified host network collides with a non-hostonly network!
The specified host network collides with a non-hostonly network!
This will cause your specified IP to be inaccessible. Please change
the IP or name of your host only network so that it no longer matches that of a bridged or non-hostonly network.
What is the best method to solve this issue? I read the Vagrant Docs and other posts but I didn't get it up and running.
** UPDATE **
I added this line to my Vagrantfile:
config.vm.network 'public_network'
This invokes a bridged mode. After choosing 'en0: Wi-Fi (Airport)' as adapter when starting the VM, the ip of my VM is now 192.168.0.100 but I still can't connect to my database #192.168.0.10.
I already did a credential check by placing all files on the NAS-webserver and all worked well.
Solution:
set the network to bridged mode
grant the VM ip address access in the mysql users table
So I just added the same user in phpMyAdmin but now with the VM ip address as hostname.
Created a new Server 8 machine. Testing out a .net + SQL Server 2012 site. I am trying to remotely connect to the machine but in order to do so I need to enable TCP/IP protocol. If I try and do it visually through the Computer Management Console I get some strange behavior in that if I try to select any Yes/No dropdown list it simply gives me a blank list and I cannot change the value. I can enable the TCP/IP as a whole by selecting it from the context menu in the config, but when I go into the properties I get enabled = No for all IP1, IP2, etc... areas.
I then tried to change it using SQLPS... but does not seem to take... the strange thing is that I notice that under properties there is nothing... take a look and let me know..
PS SQLSERVER> $MachineObject.getsmoobject($tcp.urn.Value + "/IPAddress[#Name='IP2']")
Parent : Microsoft.SqlServer.Management.Smo.Wmi.ServerProtocol
IPAddressProperties : {Active, Enabled, IpAddress, TcpDynamicPorts...}
IPAddress : 192.168.0.24
Urn : ManagedComputer[#Name='WIN-LLJKBQ6OVVR']/ServerInstance[#Name='MSSQLSERVER']/ServerProtocol[#Name
='Tcp']/IPAddress[#Name='IP2']
Name : IP2
Properties : {}
UserData :
State : Existing
When you enable TCP/IP protocol on SQL Server, not only do you enable port 1433 (or whatever) but you also need to make sure you bound the listener to the right interface. In the past, SQL server would bind to 0.0.0.0 but in recent versions you can bind to one of the many options : 127.1, 192.168.1.xx, 0:0:0:0:0:0:0:1, ::1 , etc.
Please run "SQL Server COnfiguration Manager" , look in the network configuration, and make sure you configured the listener bindings correctly. You can verify it using "netstat -an" in a shell.
Also, double check that your user account is actually enabled and that SQL Server "mixed auth" is probably enabled.