[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: |
|
||||
| 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: (cherry picked from commit f8cdf774a81b3af8825ac76eaebef1fd48183b5a) | |||||
| Comment by Githook User [ 03/Jul/19 ] | |||||
|
Author: {'name': 'Sara Golemon', 'username': 'sgolemon', 'email': 'sara.golemon@mongodb.com'}Message: | |||||
| 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.
Then it would have failed properly since there is no "net.enableMajorityReadConcern" setting. Similarly this would fail due to an invalid value:
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. |