Example needed for how to set up the oplog observer with MongoDB 2.6

[Rachel Willmer]

The documentation at https://github.com/meteor/meteor/wiki/Oplog-Observe-Driver uses the old MongoDB 2.4 syntax which does not work with MongoDB 2.6.

I've tried making a guess at what the 2.6 equivalent would be but it doesn't work, so it would be great if someone more knowledgeable could tell me what syntax to use.

I've tried creating the oplogger user like this:

PRIMARY> use admin

PRIMARY> db.createUser({'user': 'oplogger', pwd: 'PASSWORD', "roles" : [{"role" : "read", "db" : "local"}]})

and then running meteor (on a different machine) like so:

MONGO_OPLOG_URL=mongodb://oplogger:PASSWORD@MONGOHOST/local?authSource=admin MONGO_URL="mongodb://readUser:PASSWORD@MONGOHOST/DBNAME" meteor run

But meteor fails to start with an error "MongoError: not authorized for query on local.system.replset"

I'm at a bit of a loss to know how to debug this. If I log on to MONGOHOST, I can use those credentials to login to the admin database, but not the local one.

Any help or pointers would be most gratefully received

Rachel

[Rachel Willmer]

I've been digging around this some more.

So it seems that the createUser statement is good, and I can prove that by logging into the mongodb server directly from the command line using this command:

mongo -u oplogger --password PASSWORD local --authenticationDatabase admin --host MONGOHOST

Which gets me into the local database, where I can see the oplog.rs

PRIMARY>db.oplog.rs.find()

works fine

But looking more closely at the error message, what meteor is complaining about is not having access to system.replset

PRIMARY>db.system.replset.find()

gives me error: { "$err" : "not authorized for query on local.system.replset", "code" : 13 }

So I wonder whether something has changed been 2.4 and 2.6 to make the addition of extra permissions necessary?

Rachel

[Rachel Willmer]

So I've got it working now. I ended up creating a new role for oplogger with the necessary permissions.

db.runCommand({ createRole: "oplogger", privileges: [   { resource: { db: 'local', collection: 'system.replset'}, actions: ['read']}, ], roles: [{role: 'read', db: 'local'}] })

db.runCommand({ grantRolesToUser: 'oplogger', roles: ['oplogger']})

Hope that helps someone in the same boat...

Rachel

[Jens Zastrow]

Execution of command on latest mongo 2.6.1 results in an error.

"Unrecognized action privilege string: read"

[Jan Hendrik Mangold]

On 8 May 2014, at 06:53, Jens Zastrow <jens.z...@mj-networks-gmbh.de> wrote:

> Execution of command on latest mongo 2.6.1 results in an error.
>
> “Unrecognized action privilege string: read"

Doesn’t it need to be find? According to the docs there is no action read

http://docs.mongodb.org/manual/reference/privilege-actions/#security-user-actions

[Ralph Haygood]

Thanks. Per Jan Hendrik Mangold, "actions: ['read']" should be replaced with "actions: ['find']". With that change, this prescription works.

[Julien Le Coupanec]

Here is the difference between Mongo 2.4 and 2.6. (See more here about setting up oplog taling on a meteor app)

# For MongoDB 2.4
rs0:PRIMARY> db.addUser({ user:'oplogger', pwd:'pwd', roles:[], otherDBRoles:{ local: ['read'] } })  # can read everything that is written to the local database.


# For MongoDB 2.6
rs0:PRIMARY> db.createUser({ user:'oplogger', pwd:'pwd', roles:[] })
rs0:PRIMARY> db.runCommand({ createRole: "oplogger", privileges: [   { resource: { db: 'local', collection: 'system.replset'}, actions: ['find']}, ], roles: [{role: 'read', db: 'local'}] })
rs0:PRIMARY> db.runCommand({ grantRolesToUser: 'oplogger', roles: ['oplogger']})


rs0:PRIMARY> show users  # you should see the new oplogger user appear

[Jordan Garside]

Apparently you can't run this command on Compose (MongoHQ), I got an email from support:

As for roles, the only roles available are the ones that are provisioned on the database for you. We don't support the creation or addition of roles on Compose MongoDB instances.

So if you're running a Heroku instance with Compose, don't upgrade to 2.6.6 or you will lose the ability to use the opLogger.

Support was helpful though and said they can migrate me to a new database running 2.4 (since downgrading would corrupt data).