0

I inherited a server, and the original admin team is no longer around. We have a live server that is working, but I'm trying to successfully convert it to an AMI for AWS scaling.

The clones work, except for the chat feature. It uses a Node.js app for chat communications. Mongodb is the chat DB.

I've modified the app's config.json to point mongoDB to the correct FQDN of the load balancer, and mongo seems to start fine.

However, in the functioning (original) servers Mongo log...I see...

2016-07-25T18:11:15.393+0000 I NETWORK  [initandlisten] waiting for connections on port 27017
2016-07-25T18:11:30.272+0000 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:36001 #1 (1 connection now open)
2016-07-25T18:12:32.981+0000 I INDEX    [conn1] allocating new ns file /var/lib/mongodb/admin.ns, filling with zeroes...
2016-07-25T18:12:33.265+0000 I STORAGE  [FileAllocator] allocating new datafile /var/lib/mongodb/admin.0, filling with zeroes...
2016-07-25T18:12:33.268+0000 I STORAGE  [FileAllocator] done allocating datafile /var/lib/mongodb/admin.0, size: 64MB,  took 0.003 secs
2016-07-25T18:12:33.281+0000 I INDEX    [conn1] build index on: admin.system.users properties: { v: 1, unique: true, key: { user: 1, db: 1 }, name: "user_1_db_1", ns: "admin.system.users" }
2016-07-25T18:12:33.281+0000 I INDEX    [conn1]          building index using bulk method
2016-07-25T18:12:33.282+0000 I INDEX    [conn1] build index done.  scanned 0 total records. 0 secs
2016-07-25T18:12:33.282+0000 I COMMAND  [conn1] command admin.$cmd command: createUser { createUser: "admin", pwd: "xxx", roles: [ { role: "root", db: "admin" } ], digestPassword: false, writeConcern: { w: "majority", wtimeout: 30000.0 } } keyUpdates:0 writeConflicts:0 numYields:0 reslen:37 locks:{ Global: { acquireCount: { r: 4, w: 4 } }, MMAPV1Journal: { acquireCount: { w: 11 } }, Database: { acquireCount: { W: 4 } }, Collection: { acquireCount: { W: 1 } }, Metadata: { acquireCount: { W: 7 } } } 317ms
2016-07-25T18:16:25.538+0000 I NETWORK  [conn1] end connection 127.0.0.1:36001 (0 connections now open)
2016-07-26T09:35:55.261+0000 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:38409 #2 (1 connection now open)

However, on the cloned servers, I see...

2017-03-30T07:48:01.450+0000 I NETWORK  [initandlisten] waiting for connections on port 27017

...then nothing. I'm really not sure where to look, or how to determine what is supposed to be connecting from where. I'm doing a server dissection to try and figure this out.

Can anyone offer suggestions as to where to look...specifically, where the connection to port 127.0.0.1:36001 is coming from and where I should look for the config of that port (Nothing in /etc/services BTW)

1

In short: what you can see is somebody creating the first admin user, which is necessary on an authenticated database.

The port number 36001 is not significant; that's the randomly-allocated port number on the client side.

However, the ip address 127.0.0.1 is significant: that shows you that the client was connecting from the same computer. That means that it was either running right there on the db server, or running elsewhere but connecting through a tunnel.

The log entries are interesting:

  • the connection is timestamped a few seconds after the server started up, in August last year
  • there is a pause for a further minute
  • then there are logs of something happening, within the space of a second
  • the references to new files admin.ns and admin.0 confirm that the admin database was being created and first written to.
  • there is a record of a user being created
  • there is a further pause of a few minutes
  • the session is disconnected

To me, that looks like the db admin has been sorting out the authentication on a fresh server, as follows:

  • started the new mongod server process
  • connected with the mongo shell (command-line app), there on the server
  • created an admin user
  • disconnected again

The reason there's a record of it in the live server's logs, but not in the clone server's logs, is because it wasn't an automatic process - somebody manually carried out those steps. You haven't done that (yet) on the clone server, so there is no log trace of it (yet).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.