docker-server.sh put keystore config into overrides instead of default #472
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First stab at addressing #427
If docker-server.sh finds certificates mounted in '/etc/x509/certs', we make the assumption that the user wants us to manage their certificates for them. This means that we are 'safe' to put our keystore config in configDropins/overrides. This will prevent the issue reported in 427, as the generated keystore/config will override the config from the example server.xml, so there will no longer be a mismatch between keystore and keystore password.
The openssl commands will overwrite an existing keystore in the default location, so creating the keystore will always suceed, even if an existing keystore is in the container image.
If the user has run configure.sh in their dockerfile, then there will be an existing keystore.xml snippet in configDropins/defaults. This will cause a warning at server startup due to multiple definitions of the keystore config. The override will win the conflict, so it would be safe to leave the defaults keystore.xml in place, but it is probably better to try and remove it.
Again, this should be safe, as it is highly unlikely that a user would have written to this specific file location and name.
A potentially 'fail' scenario would be if a user has added a keystore + config into their container image, and also mounted certificates in /etc/x509/certs. We would then overwrite their keystore, and override their keystore config.
This is an unlikely scenario as it is not best practice to put a keystore into a container image, and in addition, the user would then be unlikely to mount certificates into /etc/x509/certs.