mongooplog is failing with unauthorized error - mongodb

Question

I am trying to replay the oplog from 1 replica set to another in mongo. I am getting an error, any idea why?
mongooplog --from "10.0.0.180:27017" -h "my_rs/10.0.0.88:27017,10.0.0.88:27018,10.0.0.88:27019" -d my_db -u dbuser -p db_pass
Fri Jun 27 14:24:21 starting new replica set monitor for replica set my_rs with seed of 10.0.0.88:27017,10.0.0.88:27018,10.0.0.88:27019
Fri Jun 27 14:24:21 successfully connected to seed 10.0.0.88:27017 for replica set my_rs
Fri Jun 27 14:24:21 changing hosts to { 0: "10.0.0.88:27017", 1: "10.0.0.88:27018" } from my_rs/
Fri Jun 27 14:24:21 trying to add new host 10.0.0.88:27017 to replica set my_rs
Fri Jun 27 14:24:21 successfully connected to new host 10.0.0.88:27017 in replica set my_rs
Fri Jun 27 14:24:21 trying to add new host 10.0.0.88:27018 to replica set my_rs
Fri Jun 27 14:24:21 successfully connected to new host 10.0.0.88:27018 in replica set my_rs
Fri Jun 27 14:24:21 successfully connected to seed 10.0.0.88:27019 for replica set my_rs
Fri Jun 27 14:24:21 Primary for replica set my_rs changed to 10.0.0.88:27017
Fri Jun 27 14:24:21 replica set monitor for replica set my_rs started, address is my_rs/10.0.0.88:27017,10.0.0.88:27018
connected to: my_rs/10.0.0.88:27017,10.0.0.88:27018,10.0.0.88:27019
Fri Jun 27 14:24:21 [ReplicaSetMonitorWatcher] starting
Fri Jun 27 14:24:21 [oplogreplay] going to connect
Fri Jun 27 14:24:21 [oplogreplay] connected
Fri Jun 27 14:24:21 [oplogreplay] starting from Jun 26 14:24:21:0
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [omongooplog --from "10.0.0.180:27017" -h "my_rs/10.0.0.88:27017,10.0.0.88:27018,10.0.0.88:27019" -d my_db -u dbuser -p db_pass
Fri Jun 27 14:24:21 starting new replica set monitor for replica set my_rs with seed of 10.0.0.88:27017,10.0.0.88:27018,10.0.0.88:27019
Fri Jun 27 14:24:21 successfully connected to seed 10.0.0.88:27017 for replica set my_rs
Fri Jun 27 14:24:21 changing hosts to { 0: "10.0.0.88:27017", 1: "10.0.0.88:27018" } from my_rs/
Fri Jun 27 14:24:21 trying to add new host 10.0.0.88:27017 to replica set my_rs
Fri Jun 27 14:24:21 successfully connected to new host 10.0.0.88:27017 in replica set my_rs
Fri Jun 27 14:24:21 trying to add new host 10.0.0.88:27018 to replica set my_rs
Fri Jun 27 14:24:21 successfully connected to new host 10.0.0.88:27018 in replica set my_rs
Fri Jun 27 14:24:21 successfully connected to seed 10.0.0.88:27019 for replica set my_rs
Fri Jun 27 14:24:21 Primary for replica set my_rs changed to 10.0.0.88:27017
Fri Jun 27 14:24:21 replica set monitor for replica set my_rs started, address is my_rs/10.0.0.88:27017,10.0.0.88:27018
connected to: my_rs/10.0.0.88:27017,10.0.0.88:27018,10.0.0.88:27019
Fri Jun 27 14:24:21 [ReplicaSetMonitorWatcher] starting
Fri Jun 27 14:24:21 [oplogreplay] going to connect
Fri Jun 27 14:24:21 [oplogreplay] connected
Fri Jun 27 14:24:21 [oplogreplay] starting from Jun 26 14:24:21:0
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 } plogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
The from parameter is also an RS (with noauth=true set), but if i try use "my_rs/10.0.0.180:27017" it fails, doesn't look like the from parameter can use an RS address.
the username and password used for the replay on 88 is in the admin db as well as my_db.
Update
I have upgraded to 2.4.10. The upgrade seems to give more meaningful logging. On 180, I can connect to the local db (without auth) and do a db.oplog.rs.count() and get results (both on local and remote connections). However, when I run mongooplog with 180 as the from, I still get an error (this is from 88):
Tue Jul 1 10:16:29.034 [oplogreplay] error getting oplog
Tue Jul 1 10:16:29.034 [oplogreplay] { $err: "not authorized for query on local.oplog.rs", code: 16550 }
and i see a similar error in 180's error logs.

Answer 1

You need to add the authentication database to the command line, as by default mongooplog is going to assume that your username and password credentials apply to the database your are applying the oplog to.
--authenticationDatabase dbname
New in version 2.4.
Specifies the database that holds the user’s credentials. If you do
not specify an authentication database, the mongooplog assumes that
the database specified as the argument to the --db option holds the
user’s credentials.
so in your case I would add --authenticationDatabase admin to your command line.

Answer 2

Mongooplog seemed to buggy around authentication, and also doesn't seem to support filtering of dbs to replicate.
I have written a tool (gem) that allows replication between 2 replica sets. It's available at https://github.com/brettcave/mongo-oplogreplay