Skip ssl on docker_temp_server_start #594
Merged
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
grooverdan
force-pushed
the
disable_ssl_on_temp_server
branch
from
d80c455
to
a01c93e
Compare
grooverdan
force-pushed
the
disable_ssl_on_temp_server
branch
from
a01c93e
to
da67226
Compare
And checking it when seeing if the server is started. Closes: MariaDB#592
grooverdan
force-pushed
the
disable_ssl_on_temp_server
branch
from
da67226
to
76b7b9e
Compare
In case of missing ssl-ca like MariaDB#594
|
Docker Official Image updated 4 hrs ago. |
This was referenced Jun 24, 2024
grooverdan
added a commit
to grooverdan/mariadb-docker
that referenced
this pull request
Jun 25, 2024
require-secure-transport on the server mandates that tls or unix socket be used. The healthcheck user doesn't have explict tls credentials, so would have failed. 11.4+ would have tls negiotated, except in MariaDB#594 it was disabled for people that didn't configure ssl-ca correctly. To resolve this _process_sql adds an explict --protocol socket to get around the default configuration of 'protocol=tcp' in .my-healthcheck.sh. The protocol=tcp was there to catch people who put `healthcheck.sh --innodb_initialized` to discover it checked that in the starting phase of the container, without a tcp connection being available, it still returned true. We work around this my making a connection test always occur in the healthcheck. Remove the protocol=tcp from the generation of .my-healthcheck.cnf files. --connect, as a method that requires to test the connection, we add a mechanims that examines @@skip_networking and considers that if false, the connection is viable. We made a unix socket connection to do the test, which is active the same time as tcp sockets are. This alternate --connect method would have only worked the credentials of the healthcheck user where valid. If it isn't fall back to looking for "Can't connect". Closes: MariaDB#596
grooverdan
added a commit
to grooverdan/mariadb-docker
that referenced
this pull request
Jun 25, 2024
require-secure-transport on the server mandates that tls or unix socket be used. The healthcheck user doesn't have explict tls credentials, so would have failed. 11.4+ would have tls negiotated, except in MariaDB#594 it was disabled for people that didn't configure ssl-ca correctly. To resolve this _process_sql adds an explict --protocol socket to get around the default configuration of 'protocol=tcp' in .my-healthcheck.sh. The protocol=tcp was there to catch people who put `healthcheck.sh --innodb_initialized` to discover it checked that in the starting phase of the container, without a tcp connection being available, it still returned true. We work around this my making a connection test always occur in the healthcheck. Remove the protocol=tcp from the generation of .my-healthcheck.cnf files. --connect, as a method that requires to test the connection, we add a mechanims that examines @@skip_networking and considers that if false, the connection is viable. We made a unix socket connection to do the test, which is active the same time as tcp sockets are. This alternate --connect method would have only worked the credentials of the healthcheck user where valid. If it isn't fall back to looking for "Can't connect". Closes: MariaDB#596
grooverdan
added a commit
that referenced
this pull request
Jun 27, 2024
require-secure-transport on the server mandates that tls or unix socket be used. The healthcheck user doesn't have explict tls credentials, so would have failed. 11.4+ would have tls negiotated, except in #594 it was disabled for people that didn't configure ssl-ca correctly. To resolve this _process_sql adds an explict --protocol socket to get around the default configuration of 'protocol=tcp' in .my-healthcheck.sh. The protocol=tcp was there to catch people who put `healthcheck.sh --innodb_initialized` to discover it checked that in the starting phase of the container, without a tcp connection being available, it still returned true. We work around this my making a connection test always occur in the healthcheck. Remove the protocol=tcp from the generation of .my-healthcheck.cnf files. --connect, as a method that requires to test the connection, we add a mechanims that examines @@skip_networking and considers that if false, the connection is viable. We made a unix socket connection to do the test, which is active the same time as tcp sockets are. This alternate --connect method would have only worked the credentials of the healthcheck user where valid. If it isn't fall back to looking for "Can't connect". Closes: #596
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.
Closes: #592