Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-9315

local.slaves is not correctly maintained in authenticated system.

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Minor - P4 Minor - P4
    • 2.4.4, 2.5.0
    • Affects Version/s: 2.4.1
    • Component/s: Replication, Security
    • None
    • Environment:
      2.6.35.14-97.44.amzn1.x86_64
    • Linux
    • Hide

      I was able to duplicate this on another unrelated replica set when doing a 2.2.3 -> 2.4.0 upgrade, but another unrelated install has no issues.

      Show
      I was able to duplicate this on another unrelated replica set when doing a 2.2.3 -> 2.4.0 upgrade, but another unrelated install has no issues.

      I noticed earlier today that our replica set has been triggering user asserts. From looking at MMS, this started immediately after doing a 2.2.2 -> 2.4.0 upgrade. When I changed the log level to 10 and grepped against the logs for "assert", I get (repeatedly):

      Thu Apr 11 01:08:21.951 [slaveTracking] User Assertion: 16538:not authorized for upsert on local.slaves
      Thu Apr 11 01:08:21.951 [slaveTracking] update local.slaves keyUpdates:0 exception: not authorized for upsert on local.slaves code:16538 0ms

      When looking on the primary server, it's missing the local.slaves collection. Restarting the primary or making it step down doesn't fix it, it's never recreated. All the commands such as rs.status() or rs.reconfig() work fine. As far as I can tell, the only issue this causes that it means the assert number isn't very useful to look at.

            Assignee:
            spencer@mongodb.com Spencer Brody (Inactive)
            Reporter:
            zanker Zachary Anker
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: