Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BadValue: need to enable SSL via the sslMode flag when using SSL configuration parameters #172

Closed
sdanieru opened this issue Apr 25, 2017 · 10 comments

Comments

@sdanieru
Copy link

Hi Folks,
I'm attempting to spin up a mongo container w/ ssl from the stock 3.4 image with something like this:
docker run -d --name dev-hrs-db -v /home/core/repos/mongodb/conf/dev-hrs-db.conf:/etc/mongod.conf -v /data/dev-hrs-db:/data -v /home/core/certs:/certs -p 27033:27033 mongo:3.4 mongod -f /etc/mongod.conf
mongod fails with this error:
BadValue: need to enable SSL via the sslMode flag when using SSL configuration parameters try 'mongod --help' for more information
Which is strange since all the ssl directives are in the conf file. When I add all the ssl directives directly on the command line, mongod gets a little further but then fails with the following error:
2017-04-25T21:25:36.135+0000 I STORAGE [initandlisten] exception in initAndListen: 20 Attempted to create a lock file on a read-only directory: /data, terminating
Also, if I just launch the container w/ -it and then manually start mongod -f /etc/mongod.conf in the container, it works just fine, which tells me the conf file is legit and accessible from within the container, and the /data mount is ok as well.
For the life of me I cannot figure out why this is happening; I have a vague suspicion that it might be an issue with permissions on the filesystem in the image relating to the -v mounts, but I really have no idea. It's also worth noting that I've had success previously with this setup, so I'm wondering if something changed in the image?

Any help is welcome!

@tianon
Copy link
Member

tianon commented Apr 25, 2017

#148 is semi-related -- this is due to the new changes introduced for "initdb" functionality (see also #169 and #167). Parsing the --config file to determine that we need --sslMode is very complex. 😞 😢

@sdanieru
Copy link
Author

Thanks for the swift response tianon; appreciate it!
For now as a workaround I've:

  1. changed the container's internal data path to /data/db
  2. passing all the ssl params on the command line so they don't need to be parsed from the yaml conf file.

@tianon
Copy link
Member

tianon commented Apr 25, 2017

Nice, so that was successful for you?

@sdanieru
Copy link
Author

yes, i've got it working now:

  1. our internal db path can be whatever, so it's no problem to change it to the default (/data/db)
  2. it's a bit cludgy to have to push ssl configuration from the conf file to the command line; is this going to be resolved in the future?

@barbarello
Copy link

i ran into this same issue both with version 3.4.3 and 3.4.4.

@tianon
Copy link
Member

tianon commented Apr 29, 2017

@sdanieru possibly -- we're debating whether it's worth trying to parse the YAML configuration, but it's a complicated proposition to do so.

The code currently only checks whether you've specified --sslPEMKeyFile for whether it should set --sslMode to allowSSL or to disabled (

sslMode="$(_mongod_hack_have_arg '--sslPEMKeyFile' "$@" && echo 'allowSSL' || echo 'disabled')" # "BadValue: need sslPEMKeyFile when SSL is enabled" vs "BadValue: need to enable SSL via the sslMode flag when using SSL configuration parameters"
), so that's technically the only one you need to "pull out". We've also considered updating that code to check for --sslMode so that one could simply specify --sslMode on the command line to inform the initdb code that SSL is necessary.

@yosifkit
Copy link
Member

yosifkit commented May 1, 2017

@tianon, then we have to check the value of --sslMode, since they could be setting it to disabled. 😞 sslPEMKeyFile was chosen since if it exists, then the server has to be using ssl.

On the other hand, you can't set sslMode disabled and still have other ssl config, since that would fail to start, so I doubt many users are setting explicit disabled.

@krish7919
Copy link

I have currently derived a docker container which takes some CLI and initializes the mongod.conf accordingly and then calls the original entrypoint.sh script with mongod --config <conf file> arguments.

It works fine till I enable SSL. The error I get is:

warning: database is not yet initialized, and "--config" is specified
  the initdb database startup might fail as a result!

BadValue: cannot have x.509 cluster authentication in allowSSL mode
try 'mongod --help' for more information

And when I specify all the parameters on the CLI, the sslMode gets set to allowSSL rather than requireSSL.

I went through the docker-entrypoint.sh script but I cannot understand why has it been hacked in the first place! Am I missing something obvious here?

@tianon
Copy link
Member

tianon commented May 4, 2017

@krish7919 it's for the new initdb behavior -- the MongoDB configuration file is a bit complex to parse via Bash (it's YAML, and doesn't match the CLI flags 1-to-1), but we need to start mongod temporarily with some slightly customized options in order to create the initial user and run any startup scripts

The sslMode parameter is only set to allowSSL for the short period that mongod is started during initdb listening only on 127.0.0.1 -- once that's done, mongod should start with whatever parameters are passed, unchanged (possibly with the addition of --auth, depending on whether username/password were specified and --auth was not already supplied).

@krish7919
Copy link

@tianon : So correct me if I am wrong:

If I start mongod with the default entrypoint script with a MONGO_INITDB_ROOT_USERNAME and a MONGO_INITDB_ROOT_PASSWORD, it would create a default admin user for further access?

And once I log in to the mongo shell using this, I can create other users and roles?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants