[SERVER-12035] clusterMonitor role missing privileges for MMS compatibility Created: 11/Dec/13 Updated: 28/Sep/16 Resolved: 14/Jan/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Diagnostics, Replication, Security |
| Affects Version/s: | 2.5.4 |
| Fix Version/s: | 2.5.5 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | John Morales | Assignee: | Spencer Brody (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
OS X 10.8.4 |
||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Steps To Reproduce: | Not particularly straightforward to repro - I modified my MMS agent to log every exception. (The standard mms.mongodb.com agent ignores a variety of command failures.) I can put together my modified version of the agent if it would help. |
||||||||
| Participants: | |||||||||
| Description |
|
The following actions/privileges are not permitted by the 2.6 clusterMonitor role in order to maintain compatibility with MMS: 1.) Permission to read the current profiling level via the {profile: -1} command. Also, not sure if related or should be separate ticket, but I'm also occasionally seeing this error from the monitoring agent log (via pymongo) when trying to run dbstats command against both of my clusterMonitor-authed shard secondaries: "expected to be write locked for config.$freelist" Corresponding trace from MongoDB server log:
|
| Comments |
| Comment by Spencer Brody (Inactive) [ 14/Jan/14 ] | ||||||||||||||||||||||||||||
|
https://github.com/mongodb/mongo/commit/e6257f5996ffcfb3c1d1b1aed734a599b05d3456 <- Fixes sporadic test failure. | ||||||||||||||||||||||||||||
| Comment by Githook User [ 13/Jan/14 ] | ||||||||||||||||||||||||||||
|
Author: {u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@10gen.com'}Message: | ||||||||||||||||||||||||||||
| Comment by Githook User [ 08/Jan/14 ] | ||||||||||||||||||||||||||||
|
Author: {u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@10gen.com'}Message: | ||||||||||||||||||||||||||||
| Comment by Githook User [ 08/Jan/14 ] | ||||||||||||||||||||||||||||
|
Author: {u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@10gen.com'}Message: | ||||||||||||||||||||||||||||
| Comment by Andy Schwerin [ 16/Dec/13 ] | ||||||||||||||||||||||||||||
|
I propose that we add the data to the self entry in replSetGetStatus. I propose a field named earliestOptime with the same type and form as the optime field. | ||||||||||||||||||||||||||||
| Comment by John Morales [ 11/Dec/13 ] | ||||||||||||||||||||||||||||
|
True - to be clear, it's only capturing the first/last entry's timestamp for the timespan, but perhaps there is a different way to obtain this info. E.g., example from ping data:
| ||||||||||||||||||||||||||||
| Comment by Andy Schwerin [ 11/Dec/13 ] | ||||||||||||||||||||||||||||
|
Is reading the oplog the only way to get oplog stats? I ask because it provides read access to all user data modifications, which isn't typically desirable for a monitor. |