[DOCS-5959] Document how to import an authenticated deployment into automation Created: 03/Aug/15 Updated: 13/May/16 Resolved: 26/Aug/15 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | Cloud Manager |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Andrew Davidson | Assignee: | Kay Kim (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | collector-298ba4e7 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Location: https://docs.opsmanager.mongodb.com/current/tutorial/add-existing-host-to-automation/ |
||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Days since reply: | 8 years, 25 weeks ago | ||||||||
| Description |
|
It is critical that we explain in "import" documentation how auth is handled. For example this blog post contains more information http://blog.cloud.mongodb.com/post/111860709590/introduction-to-import-existing-deployment-for in the sense that it is shown that you would need to pre-create an Automation agent user to grant the Automation agent permissions on the attached-to cluster. Importing a cluster with Auth enabled is a complicated operation: 2) If a Group's Deployment already has an authentication profile enabled (e.g. isn't in a completely blank fresh state) then attached-to processes will require the mms-automation user be pre-created on them with appropriate permissions and password based on what the Automation agent expects (e.g. if "Mongodb-CR" is used then *Manager will have pre-created a random password for the mms-automation user which can be found in the Automation configuration for the Group's Deployment". 3) Note that a Group's Deployment can have authentication enabled even if there are no managed MongoDB processes (e.g. an empty deployment) which is a particularly awkward context to be unable to attach to a cluster that doesn't have the precisely correct user created yet. Separately, attaching to an auth-enabled cluster where the Group's Deployment doesn't yet have "auth" enabled will cause the auth settings from the new deployment to be mimic'd in the Deployment. This is handy and we should point it out. In an ideal world, when attaching to a cluster with auth enabled: |
| Comments |
| Comment by Githook User [ 26/Aug/15 ] |
|
Author: {u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}Message: |
| Comment by Githook User [ 26/Aug/15 ] |
|
Author: {u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}Message: |