Additional mandatory fields in settings.json for upgrade from 1.1.5

[fantawttw]

In API version 1.1.5 I didn't have the db.username or db.password in the settings.json file and it picked up the ENV versions and used those. When upgrading to 1.1.8 however I couldn't get the API to stay running as a service it ran correctly when running the node dist/api.js command which was strange.

Adding the 'username' and 'password' to the settings file however allowed it to work again, remove them and it fails. Looking at the commit history I think this relates to Fixed db auth issues with docker containers.

I think a simple update on the read.me so that it reads Config settings for the following have changed. db authentication has changed so ensure you update your config/settings.json to include 'username' and 'password' logging has also changed so ensure you update your config/settings.json file if you have customised logging settings.

[nero120]

Hi @fantawttw, v1.1.8 should still pick up the db username and password from ENV variables if not set in settings.json, in fact I'm running it locally right this moment and my settings.json looks like:

{
  "dailyNewSyncsLimit": 0,
  "status": {
    "message": "Dev server"
  }
}

The commit you referenced merely changed the way the username and password are provided to mongodb (in the uri rather than the options object), which is more typically for mongodb.

Double check that your local settings.json does not contain db username/password and settings.default.json contains:

"username": "",
"password": "",

under db.

The other possible issue is that you are not specifying the correct authSource. I suspect when you created the service originally, you followed the instruction to create the db user in the xbrowsersync database. In v1.1.6 this changed and now the user is expected to be contained in the admin database. If this is the case, you can either move the user, or simply update your settings.json to include "authSource": "xbrowsersync" under db.

[fantawttw]

Hi @nero120 , thanks for the quick response. You are indeed correct that when I created the service originally I followed the original instructions and created the db user in the xbrowsersync db As you mentioned in the upgrade instructions I added the new authsource entry to the settings.json file. Issued the git pull and npm install --unsafe-perm

This is where things get interesting. having the following in settings.json

"db": {
    "authSource": "xbrowsersync"
  },

then If I run the command node dist/api.js from the command line the service works as expected. If however I start it via init.d then it throws the following error into xbrowsersync/api.log {"name":"xBrowserSync_api","hostname":"xBrowserSynctest","pid":379,"level":50,"req":null,"err":{"message":"failed to connect to server [127.0.0.1:27017] on first connect[MongoNetworkError: connect ECONNREFUSED 127.0.0.1:27017]","name":"MongoNetworkError","stack":"MongoNetworkError: failed to connect to server [127.0.0.1:27017] on first connect [MongoNetworkError: connect ECONNREFUSED 127.0.0.1:27017]\n at Pool.<anonymous> (/root/API/node_modules/mongodb-core/lib/topologies/server.js:564:11)\n at Pool.emit (events.js:182:13)\n at Connection.<anonymous> (/root/API/node_modules/mongodb-core/lib/connection/pool.js:317:12)\n at Object.onceWrapper (events.js:273:13)\n at Connection.emit (events.js:182:13)\n at Socket.<anonymous> (/root/API/node_modules/mongodb-core/lib/connection/connection.js:246:50)\n at Object.onceWrapper (events.js:273:13)\n at Socket.emit (events.js:182:13)\n at emitErrorNT (internal/streams/destroy.js:82:8)\n at emitErrorAndCloseNT (internal/streams/destroy.js:50:3)\n at process._tickCallback (internal/process/next_tick.js:63:19)"},"msg":"Database error","time":"2019-01-15T11:51:22.999Z","v":0}

by changing settings.json to

"db": {
    "username":"xbrowsersyncdb",
    "password":"xbrowsersync",
    "authSource": "xbrowsersync"
  },

then it works as a service also.

The API server is running on AlpineLinux as a Proxmox VM. So I can snapshot and quickly rollback, create a test machine etc to fix these issues so it's not a huge problem for me.

As I say I've got it working now. This might be useful for someone in the future who has a similar problem.

[nero120]

Ah I see! If you're running it as a linux service I believe you will have issues accessing custom environment variables (see here).

Glad you've got it working now, I'll close this.