Ops Manager currently allows the ability to rotate audit logs based on the threshold settings in the Update MongoDB Log Settings modal but audit.logs do not compress/delete as the mongodb.logs do from the same modal. We would like the ability to either toggle compression/deletion of audit.log in that modal or a separate modal. We think a separate modal would be better since audit.logs may be used for security forensics and require a longer retention period.

SAML is available as an authentication mechanism and we're currently using it with keycloack (centralized identity provider).

It works well with Ops Manager but there seems to be no support whatsoever in Ops Manager 4.4 API to programmatically add / update / delete SAML groups on Organizations or Projects.

The official API documentation doesn't even recognize that SAML is available.

Mongo support has confirmed that and it's a target feature in their internal backlog.
This idea will hopefully speed up things.

Ops Manager automation currently uses an mms-automation user for node management, but the password for that user is set once and stays forever unless it is updated via the Ops Manager API.

This feature would provide a mechanism that allows this password to be re-generated via the UI or an API call and have it automatically updated on the managed mongod instances as well.

If you are using local key file encryption and backing up your MongoDB deployment using Ops Manager, backups won't work correctly if you upgrade to MongoDB 4.2. The correct solution is to switch your encryption to KMIP. But if you try doing that, automation will get stuck!

In order to separate replication, client and administrative traffic, servers may have multiple network interfaces using different IP and hostname aliases associated with them.

According to the requirements described on https://docs.opsmanager.mongodb.com/current/tutorial/provisioning-prep/#server-networking-access Automation currently can use only the server hostname defined as hostname -f and cannot use any of the other aliases matching to other IP addresses for the other machine host aliases.

Please add some way to customize which host alias Automation should use as a configuration parameter for the Agent.

Currently the option of "security.TransitionToAuth" is not available in Ops Manager as "transitionToAuth" is automatically added to each node in a rolling fashion by the Automation agent and then ultimately removed when authentication is finally turned on for all nodes.

Allowing this option through Ops Manager will enable the mongod to accept and create authenticated and non-authenticated connections to and from the connected clients. Thus the clients can use this feature to avoid downtime at their end while the connection settings are updated to use the appropriate user to connect to mongod.

Problem Statement,
What is the problem? MongoDB Agent (Automation Module) attempts to auth with __system (SCRAM) user when security.clusterAuthMode is set to x509.

Why is this a problem? MongoDB Server process logs are flooded by unnecessary noise from such MongoDB Agent (Automation Module) failed auth attempts.

Example,
{"t":{"$date":"2021-05-10T11:08:02.115+0000"},"s":"I", "c":"ACCESS", "id":20249, "ctx":"conn115","msg":"Authentication failed","attr":{"mechanism":"SCRAM-SHA-1","principalName":"__system","authenticationDatabase":"local","client":"10.10.10.10:46765","result":"AuthenticationFailed: ###"}}

Proposal,
* Don't attempt to auth with __system (SCRAM) user when security.clusterAuthMode is set to x509 in MongoDB Server

In Windows, managed MongoDB processes are installed as services. In Linux, they are not. It would be great if managed processes were installed as services so that system administrators would have better control over startup and shutdown behavior, among other things.

In Ops Manager ,Whenever we do changes in the configuration the deployed mongodb instnaces ,GUI prompt for Review & Deploy ,If we have a provision for schduling the deployment in later time would fullfil the real Automation.

• Do the changes at convenient time
• Do deploy thru a schedulers

Starting with MongoDB 4.2 we are able to rotate the internal authentication keyfiles in a rolling fashion with the procedure described here:
https://docs.mongodb.com/manual/tutorial/rotate-key-sharded-cluster/

Currently when you import for automation a cluster that is using a different keyfile than the one in the automation config a bouncerestart is triggered. We can avoid it by doing a rolling rotation of the keyfile.

The old keyfile should be kept and the new one appended to it in a rolling fashion. We may have already this implemented for the "Rotate keyfile" feature present in the Security tab page.

Currently, Ops Manager does not support stop/start/restart BI Connector that is managed by Ops Manager Automation. There is only a Terminate option available.

Right now if you want to change the credentials for the monitoring agent or the backup agent, you've got to make separate API calls. Why not make it so that you can specify everything at once in the same automationConfig API PUT?

When reviewing changes in automation, warn if deploying changes will require a rolling restart.

As an example, look at the documentation for server parameters: https://docs.mongodb.com/manual/reference/parameters/

Many parameters include the description "You can only set THIS during start-up", but a warning that setting this parameter implies restarting MongoDB is missing from Ops Manager (or Cloud Manager).

As of mongocli version 1.17.0 there is no way to enable monitoring and backup modules for a cloud manager or ops manager project.

You can only query the agents and the modules enabled.

This won't allow you to use mongocli to setup a new project from scratch and will require to use the Cloud Manager or Ops Manager API updating the automation config manually for this purpose.

Hello,

I have an idea about the Keyfile rotation. So actually you can rotate the Keyfile only through the ops manager manually. But I would recommend to do this automatically with an API. This would help us alot since we have alot of mongoDB instances and this would save alot of time.

We would like to have an option in the Ops Manager UI to select certain MongoDB versions to be automatically downloaded by Automation in order to avoid downloading all major binaries.

It is not good to have several MongoDB binaries using disk space and not being used.

When reviewing changes in automation, warn if deploying changes will require a rolling restart.

As an example, look at the documentation for server parameters. Many parameters include the description "You can only set THIS during start-up", but the the warning that setting this parameter necessitates a restart is missing from Ops Manager (or Cloud Manager).