Is python code connecting locally to mongoc

Hello, I wonder if someone could answer this question.

On a Centos 7 server, we have a process running

root 1779 1 1 2018 ? 12-02:50:11 /bin/mongod -f /etc/mongodb/mongoc.conf

This is version v3.4.2

Also on same server is tool that calls following python code:

self.db = pymongo.MongoClient(host=defs.CONNECT_STRING,
                                ssl=True,
                                ssl_certfile=defs.CERTFILE_LOCATION,
                                ssl_cert_reqs=ssl.CERT_REQUIRED,
                                ssl_ca_certs=defs.CA_CERTS_LOCATION)
self.valid_connection = self.db.pcap_api.authenticate(defs.CONNECTION_AUTHENTICATION_STRING,
                                                              mechanism='MONGODB-X509')

Is it correct to state that the code, when making a pymongo.MongoClient “connect”, is making a connection locally on the same server to the mongo process seen above?

Also, may be worth pasting a snippet of the conf file:

net:
port: 27018
bindIp: 1.2.3.4 <<< ip of server being discussed here
ssl:
mode: requireSSL
PEMKeyFile: /etc/mongodb/CRPdgMUSsalt01.pem
clusterFile: /etc/mongodb/cluster.pem
CAFile: /etc/mongodb/CACerts.crt

Hi @charles_dillard

You can’t make that assumption. It depends on the contents of defs.CONNECT_STRING in the code, which can specify everything from the server IP/hostname, port, default database and other connection details.

You can find more details on this parameter here. To ensure a connection to localhost, you’d either want to ensure the host argument specified that explicitly, or omit a value for host entirely, which will tell MongoClient to default to localhost on the default port (which is 27017).

Hope this helps!

Mark

1 Like
  1. Is it ok to run

from pymongo import MongoClient
c = MongoClient()
c.test_database

on server in question as a test? This is a production server, so need to be careful.

  1. Also, the “defs.CONNECT_STRING” is set by this command:

CONNECT_STRING = os.environ.get(‘MONGO_URL’)

When I run os.environ.get for the MONGO_URL I get “none”. Also, MONGO_URL doesn’t show up in env variables. So same question: Is this likely connecting to localhost?

Thanks for your help. Trying to debug old pcap retrieval code on production system.

Hi @charles_dillard

In terms of running PyMongo MongoClient, it’ll default to 27017 as the ‘standard’ port and based on your configuration file above which indicates the server is running on 27018, you’ll need to amend the port value at the very least. I’m not sure which version of PyMongo is being used so you may need to look for an older version of this (the current version’s) page https://pymongo.readthedocs.io/en/stable/api/pymongo/mongo_client.html

You can use should be able to use ‘pip list’ to determine what the local/system version of PyMongo is being run and then look to that version of the Python driver in the readthedocs page.

Hope this helps!
Eoin

1: MongoClient instantiation and getting a collection are lazy, so the code you’ve listed will pass even if mongod isn’t there to connect to. You’ll need to do some kind of operation to check - I recommend a ping, like so:

from pymongo import MongoClient
c = MongoClient()
c.admin.command('ping')

This should return something like {u'ok': 1.0}, indicating that the server could be successfully contacted.

You could also try querying the local database, which may be able to tell you something useful about the host your code is connecting to: https://docs.mongodb.com/manual/reference/local-database/ (try printing out the result of calling find_one() with no parameters, which should contain a “hostname” field.

2: If the host is None then MongoClient will attempt to connect to localhost on port 27017. Given that your mongod is configured to listen on port 27018, I would expect your client code to fail.

1 Like

:scream:

3.4 EoL Jan 2020
3.6 EoL April 2021

Ok, will check it out. Thanks everyone for your help on this issue.

1 Like

Hi @charles_dillard,

As an addendum to @chris’ comment on MongoDB 3.4 reaching End of Life in Jan, 2020 (no further updates including security fixes), I would also strongly recommend upgrading to the final MongoDB 3.4.24 release while you plan for a major version upgrade to a supported release series (currently 4.0 or newer).

Minor releases only include bug fixes and non-backward breaking changes, so upgrading within the 3.4.x release series is not a high risk decision. There have been 22 minor releases and many improvements in the three years following MongoDB 3.4.2 (Feb 1, 2017). I also think it is much more likely that you will encounter a known issue in a low numbered release like 3.4.2.

Regards,
Stennie

1 Like