[SERVER-41903] Add --validate option to validate config file and command line only Created: 25/Jun/19  Updated: 29/Oct/23  Resolved: 03/Jul/19

Status: Closed
Project: Core Server
Component/s: Usability
Affects Version/s: None
Fix Version/s: 4.2.0-rc3, 4.3.1

Type: New Feature Priority: Minor - P4
Reporter: Eric Sommer Assignee: Sara Golemon
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Backwards Compatibility: Minor Change
Backport Requested:
v4.2
Sprint: Security 2019-07-15
Participants:

 Description   

A --validate option would cause mongod to parse config file and command line options only and not start. It would return either success or an error message if the config file or command line was malformed or invalid.



 Comments   
Comment by Githook User [ 09/Jul/19 ]

Author:

{'name': 'Sara Golemon', 'email': 'sara.golemon@mongodb.com', 'username': 'sgolemon'}

Message: SERVER-41903 Validate server parameter names during config validation

(cherry picked from commit f8cdf774a81b3af8825ac76eaebef1fd48183b5a)
Branch: v4.2
https://github.com/mongodb/mongo/commit/96bb83d7fd650605413186a42a5de16289673d35

Comment by Githook User [ 03/Jul/19 ]

Author:

{'name': 'Sara Golemon', 'username': 'sgolemon', 'email': 'sara.golemon@mongodb.com'}

Message: SERVER-41903 Validate server parameter names during config validation
Branch: master
https://github.com/mongodb/mongo/commit/f8cdf774a81b3af8825ac76eaebef1fd48183b5a

Comment by Sara Golemon [ 02/Jul/19 ]

Per slack conversation; I'll make this ticket about adding setParameter name validation to --outputConfig

Comment by Sara Golemon [ 02/Jul/19 ]

Also, if your goal is validating that set parameters exist, then you can solve this in a much more lightweight manner than invoking the server as an external process.

As of 4.2, all setParameters available to the server are defined in .idl files throughout the server sources (example: https://github.com/mongodb/mongo/blob/ca904a1e30c3163806595db8cb5c14df6a7b4ab2/src/mongo/db/cloner.idl#L31 ).  If you write a small script to collect these settings and make a local list of them in OpsManager, then you can not only validate them, but also provide a typeahead/autocomplete kind of feature in the UI.

Comment by Sara Golemon [ 02/Jul/19 ]

It does a tiny bit more than just "parses as valid YAML" file. It also checks for valid structure, and to a /limited/ degree valid setting content.
For example, if you had tried to put add:

net:
  enableMajorityReadConcern: false

Then it would have failed properly since there is no "net.enableMajorityReadConcern" setting.

Similarly this would fail due to an invalid value:

storage:
  journal:
     enabled: purple

The problem with setParameter is that the possible combination of set parameters is not known at config parse time, it's just a string map, so from a setting standpoint, that is a valid config. Similarly, if your net.bindIp was pointing an address you don't control like 255.255.255.42, it would pass the config parsing, even though that server would never start.

That said, we do know the set of valid server parameters at startup time so we could probably add some very lightweight checking, but we don't want the server to get too far along in startup for a simple validation test.

Comment by Sara Golemon [ 01/Jul/19 ]

Have you looked at https://jira.mongodb.org/browse/SERVER-36380 `./mongod --outputConfig` ?

This was designed for resolving config expansions, but in the process it also parses the config file and CLI options and performs validation rules directly attached to the options.  So depending on what validation you want performed, this might be exactly what you're looking for.  On successful parse, it dumps a YAML representation of the config and exits with success (exitcode==0).  If any option does not exist, or is configured with an invalid value, then an error is printed and the process exits with a non-zero exit code.

For your use case, you could run with this option and ignore the output on success, or capture it to show the user on failure.

Generated at Thu Feb 08 04:59:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.