Ops Tools
216 results found
-
Provide a feature to monitor the Alert payload being sent out from Ops Manager to the configured Webhook endpoint and etc.
What is the problem that needs to be solved?
Provide a feature to monitor the Alerts payload being sent out from Ops Manager to the configured Webhook endpoint and other AlertsServices endpoint.Why is it a problem? (the pain)
Currently, Ops Manager does not log the successful/failed payload of the Alerts being sent out to the configured Webhook endpoint. It is difficult to diagnose the problem with the configured Alert Services.2 votes -
Plugin for Moogsoft monitoring tools.
Currently, Ops Manager does not have the plugin for Moogsoft monitoring tools, it would be great to add the feature to the future release of Ops Manager.
2 votes -
Create localhost exception for POST /unauth/users API call
The purpose of this request is for Ops Manager to implement a "localhost exception" for the API call POST /unauth/users so it can only be executed under two conditions:
1. No other users exists in the setup.
1. Ops Manager runs in "invitation only" mode.
1. Ops Manager has not been configured for LDAP.
1. The API call can only originate from an IP or alias that belongs to one of the Ops Manager Application server.2 votes -
MongoDB Agent alters the root $PATH variable
The MongoDB Agent installation via RPM adds the /var/lib/mongodb-mms-automation/bin to root's $PATH by placing the mongodb-mms-automation-agent.sh script under the /etc/profile.d:
$ pwd
/etc/profile.d
$ sudo cat mongodb-mms-automation-agent.sh
export PATH=/var/lib/mongodb-mms-automation/bin:${PATH}This breaks my customers security standards.
Moving the script does not appear to affect the functionality of the MongoDB Agent and updating the agent via the OM UI does not add back the script.
We would like the ability to either select the contents of the MongoDB Agent rpm or be asked during the rpm installation whether or not to install the mongodb-mms-automation-agent.sh script.
2 votes -
Allow configuring custom builds at the organisation or global level (Admin panel)
It must be done at the project level at the moment, generating an operational costs for those environments with a large number of projects.
2 votes -
Provide safety mechanism for limiting MongoDB versions amongst different projects
Restrict the user depending on the type of project: dev, prod, etc to select a specific set of MongoDB Server versions that can be deployed.
Prior to 4.2 this was accomplished with version manager.
2 votes -
Ops Mgr "Insufficient oplog size" is confusing and prevents backups
When using Ops Manager UI (I've not checked the API) to declare a MongoDB cluster to be backed up, Ops Manager tries to be a good citizen and check to see if the clusters oplogs are large enough, based on their recent usage to hold at least 3 hours worth of data based on the last 24 hours of usage patterns. if the check fails, the user is prevented from enabling backup and is shown the warning:
"Insufficient oplog size: The oplog window must be at least 3 hours over the last 24 hours for all members of replica set…
2 votes -
Allow to configure separate SNMP v2C community for SNMP v2C Heartbeat Traps and SNMP v2C Alert Traps
What is the problem that needs to be solved? Allow to configure separate SNMP v2C community for SNMP v2C Heartbeat Traps and SNMP v2C Alert Traps.
Why is it a problem? (the pain) As of now (2020-03-24) there's no way to configure separate SNMP v2C community for SNMP v2C Heartbeat Traps and SNMP v2C Alert Traps (
snmp.communitycontrols both, Heartbeat and Alert Traps sent from Ops Manager's Application Server), some SNMP Monitoring Teams require different SNMP v2C communities for different set of SNMP v2C Traps (to separate Heartbeat Traps and Alert Traps).2 votes -
Group Host Mapping IPs to be added by default to Programmatic API Keys IP Whitelisting
As part of the Programmatic API Keys introduced in MongoDB Ops Manager 4.2, it would be good to have the IPs listed in the Host Mappings of a Project Deployment to be added as default whitelisted IPs when setting up a Programmatic API Key for same Project.
2 votes -
clear text password for mongodb ldap authorization
Add the feature to Encrypt the queryPassword parameter for LDAP in the config file directly via Ops Manager , so that text password should not be present in config file.
Keeping direct password is a security concern.
Sample format of the config file:ldap:
authz:
queryTemplate: '{USER}?memberOf?base'
bind:
method: simple
queryPassword: <Password>
queryUser: <username>
servers: serevername:port
transportSecurity: tls
userToDNMapping: '[ { match : "xxxxx)))"
} ]1 vote -
Set log file permissions using Ops Manager
Currently there is no way to set the log file permissions from Ops Manager and the default value is 600. Our organization uses Splunk and with the current settings the Splunk user is not able to read the log files. Config file options such as processUmask and honorSystemUmask can be used to change the log file permissions, but they will also change other files such as journal files, wiredtiger files, etc. The only option we have is to add the Splunk user to our role group in Unix, but this causes a security issue.
1 vote -
OPS Manager should call updateUser to change password to trace it in DB Audit.
If you enable auditing in database, you can't trace change password actions. The reason is OPS Manager updates system.user collection record directly. as a result, this action is not traceble in audit if parameter auditAuthorizationSuccess is not enabled.
But enabling this parameter cause performance degradation as all DML/DDL will be sent through audit layer.
Dropping user at the same time happening as expected and traceable in audit files.
1 vote -
Agent authentication to opsmanager using x509 credentials
Similar to how Opsmanger can use x509 to manage deployments, it should be possible to configure the agents to use x509 credentials to communicate with Opsmanager. This will allow for a more consistent security posture across the whole mongodb/opsmanager stack. It would also simplify security procedures such as credential rotation by unifying the authentication mechanism.
This will be an alternative to the existing API Key approach https://www.mongodb.com/docs/ops-manager/current/tutorial/manage-agent-api-key/index.html
1 vote -
Ability to remove parameter tlsCertificateKeyFilePassword from Advanced configuration
Currently the behavior around this parameter is tricky -once you added this parameter to advanced config - you can't remove it. if you try to remove it - OPS Manager simply ignores this action and when you run "Review and Deploy" - it displays nothing but still let you deploy this "nothing". similar if you want to set the value of this parameter to empty string from something - OPS Manager ignores it and deploy empty list of actions.
the workaround is to remove both tlsCertificateKeyFile and tlsCertificateKeyFilePassword in advanced config, but don't deploy it. then add back tlsCertificateKeyFile parameter…
1 vote -
When changing snapshot retention, prompt user to apply new policy to existing snapshots
Currently when you change the snapshot schedule, the changes only apply to NEW snapshots.
Please allow the user the option to apply the new policy automatically to all existing snapshots. Or at the very least, notify them of them of snapshots that exist which do not meet the current policy!
Let me provide an example of the problem. If you have a retention policy of 10 days and on DAY1 you change it to 30 days, your retention will look like this:
DAY1 - 10 snapshots
DAY2 - 10 snapshots
...
DAY10 - 10 snapshots
DAY11 - 11 snapshots
DAY12…1 vote -
Lock enableLocalConfigurationServer setting on OPS Manager side
To harden security for mongodb deployment managed by OPS Manager, we can use setting enableLocalConfigurationServer = true so automation-mongod.conf won't have any passwords for ssl certs and agent will retrieve them from OPS Manager.
to disable this feature and to read all passwords for ssl certs (and hence get access to mongodb data) it's enough to comment out this parameter an restart automation service (or wait until host will be restarted).
Linux root user can modify any file on mongodb host including this file and can restart any services, so it's impossible to protect getting all passwords and mongod.conf from…
1 vote -
I found what I believe to be an error in the following document
I found what I believe to be an error in the following document.
https://www.mongodb.com/docs/ops-manager/current/tutorial/install-simple-test-deployment/In the section "5. Create the Ops Manager Application Database directory," it instructs to execute the following command
sudo chown -R mongod:mongod /dataIn my environment, the mongod user does not exist and I get an error, but looking at the passwd file, the mongodb user and mongodb group seem to exist. The version is 11.7.
I think the correct command is as follows
sudo chown -R mongodb:mongodb /data1 vote -
Operating System distribution and version of a host in OPS Manager API
Hi,
would be useful having the operating system distribution and version of a host for our automation scripts.
This info is not available in any OPS Manager API request, as the case 01119828.
My suggestion is add this info at "Get Host by ID" https://www.mongodb.com/docs/ops-manager/current/reference/api/hosts/get-one-host-by-id/
Best regards,
Danilo1 vote -
Ability to mark a deployment as an INELIGIBLE restore target
Restoring to a cluster is one of the few destructive actions that Ops Manager takes and it's terrifying to see our main production cluster listed as a possible restore target!
I would love to be able to toggle a setting on this cluster to indicate that it is NOT available as a restore target.
This could be similar to the AWS "DisableApiTermination" feature that prevents instance termination.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#Using_ChangingDisableAPITermination1 vote -
Add flexibility to disable and enable specific fetures of managing mongodb instance in OPS Manager (like user Sync)
Currently , Mongodb admin can not select to disable or enable feature after put mongodb manageed under OPS Manager. like security control .
Normally , Security control is not mongodb or Ops manager admin's responsibility , which is managed by a enterprice access control team.
1 , In opsmanager , there is not role for security control, like useradmin in mongodb.
2 , When ACCESS control team create role in mongodb. Ops Manager sycn it back.
3 , Opsmanager admin have to be engaged to work with ACCESS control team to complete the task.It is kind of not least…
1 vote
- Don't see your idea?