This is an extra to the four built-in role grants that should be sufficient for a backup and restore program: "backup", "restore", "clusterMonitor" and "readWrite" (on admin).
This extra, custom role is only needed during restore, to get past hiccups we've found can happen trying to run the applyOps command on some system collections. (The "restore" role is meant to grant that in theory, but it doesn't completely.)
In theory there should be no need to ask the user to do this manually, either during first installation or later because the restore role includes the ability to create and modify users. So instead the PBM software could make the custom anyResource + anyAction role at an early stage during the restore and delete it when it finishes.
If we do this we can remove the need to create and grant the role during installation of PBM.
Restoring pbm user vs. restored pbm user
A second thing to potentially fix is the account of the user the pbm-agents authenticated with after the restore of the admin db is complete. There are three things:
If the user account doesn't exist it should be inserted, with the same password and roles. An old pbm user account presumably exists in the backup this case, but having only that will probably trip up the DBA doing the restore.
If it exists but has a different password it should be set to the newer value (not the one restored from the backup). This is making a decision that the password the DBA knew when they began the restore is preferred to the one that existed at the time of the backup.
If the pbm user exists but after restore completes it doesn't have all the roles the current pbm software expects those should be additionally granted to it.
anyResource + anyAction role
As of v1.0 we require the user to create the role below and grant it to the pbm user:
db.getSiblingDB("admin").createRole({ "role": "pbmAnyAction", "privileges": [ { "resource": { "anyResource": true }, "actions": [ "anyAction" ] } ], "roles": [] })This is an extra to the four built-in role grants that should be sufficient for a backup and restore program: "backup", "restore", "clusterMonitor" and "readWrite" (on admin).
This extra, custom role is only needed during restore, to get past hiccups we've found can happen trying to run the applyOps command on some system collections. (The "restore" role is meant to grant that in theory, but it doesn't completely.)
In theory there should be no need to ask the user to do this manually, either during first installation or later because the restore role includes the ability to create and modify users. So instead the PBM software could make the custom anyResource + anyAction role at an early stage during the restore and delete it when it finishes.
If we do this we can remove the need to create and grant the role during installation of PBM.
Restoring pbm user vs. restored pbm user
A second thing to potentially fix is the account of the user the pbm-agents authenticated with after the restore of the admin db is complete. There are three things:
If the user account doesn't exist it should be inserted, with the same password and roles. An old pbm user account presumably exists in the backup this case, but having only that will probably trip up the DBA doing the restore.
If it exists but has a different password it should be set to the newer value (not the one restored from the backup). This is making a decision that the password the DBA knew when they began the restore is preferred to the one that existed at the time of the backup.
If the pbm user exists but after restore completes it doesn't have all the roles the current pbm software expects those should be additionally granted to it.