RepoMirrors
/
haproxy
mirror of http://git.haproxy.org/git/haproxy.git/
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
haproxy/reg-tests/server/cli_set_ssl.vtc

61 lines
1.7 KiB
Plaintext
Raw Normal View History

MEDIUM: cli/ssl: configure ssl on server at runtime in the context of a progressive backend migration, we want to be able to activate SSL on outgoing connections to the server at runtime without reloading. This patch adds a `set server ssl` command; in order to allow that: - add `srv_use_ssl` to `show servers state` command for compatibility, also update associated parsing - when using default-server ssl setting, and `no-ssl` on server line, init SSL ctx without activating it - when triggering ssl API, de/activate SSL connections as requested - clean ongoing connections as it is done for addr/port changes, without checking prior server state example config: backend be_foo default-server ssl server srv0 127.0.0.1:6011 weight 1 no-ssl show servers state: 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - -1 where srv0 can switch to ssl later during the runtime: set server be_foo/srv0 ssl on 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - 1 Also update existing tests and create a new one. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2020-11-14 18:25:33 +00:00
varnishtest "Set server ssl via CLI"
feature ignore_unknown_macro
# for "set server <srv> ssl"
#REQUIRE_VERSION=2.4
REGTEST: server/cli_set_ssl.vtc requires OpenSSL Add OpenSSL as a requirement for this test.
2020-11-18 16:41:28 +00:00
#REGTEST_TYPE=devel
#REQUIRE_OPTIONS=OPENSSL
MEDIUM: cli/ssl: configure ssl on server at runtime in the context of a progressive backend migration, we want to be able to activate SSL on outgoing connections to the server at runtime without reloading. This patch adds a `set server ssl` command; in order to allow that: - add `srv_use_ssl` to `show servers state` command for compatibility, also update associated parsing - when using default-server ssl setting, and `no-ssl` on server line, init SSL ctx without activating it - when triggering ssl API, de/activate SSL connections as requested - clean ongoing connections as it is done for addr/port changes, without checking prior server state example config: backend be_foo default-server ssl server srv0 127.0.0.1:6011 weight 1 no-ssl show servers state: 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - -1 where srv0 can switch to ssl later during the runtime: set server be_foo/srv0 ssl on 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - 1 Also update existing tests and create a new one. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2020-11-14 18:25:33 +00:00
# Do nothing. Is there only to create s1_* macros
server s1 {
} -start
REGTESTS: use -dW by default on every reg-tests Every reg-test now runs without any warning, so let's acivate -dW by default so the new ones will inheritate the option. This patch reverts 9d511b3c ("REGTESTS: enable -dW on almost all tests to fail on warnings") and adds -dW in the default HAPROXY_ARGS of scripts/run-regtests.sh instead.
2024-11-19 15:51:30 +00:00
haproxy h1 -conf {
MEDIUM: cli/ssl: configure ssl on server at runtime in the context of a progressive backend migration, we want to be able to activate SSL on outgoing connections to the server at runtime without reloading. This patch adds a `set server ssl` command; in order to allow that: - add `srv_use_ssl` to `show servers state` command for compatibility, also update associated parsing - when using default-server ssl setting, and `no-ssl` on server line, init SSL ctx without activating it - when triggering ssl API, de/activate SSL connections as requested - clean ongoing connections as it is done for addr/port changes, without checking prior server state example config: backend be_foo default-server ssl server srv0 127.0.0.1:6011 weight 1 no-ssl show servers state: 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - -1 where srv0 can switch to ssl later during the runtime: set server be_foo/srv0 ssl on 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - 1 Also update existing tests and create a new one. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2020-11-14 18:25:33 +00:00
global
ssl-server-verify none
defaults
mode http
REGTESTS: extend the default I/O timeouts and make them overridable With the CI occasionally slowing down, we're starting to see again some spurious failures despite the long 1-second timeouts. This reports false positives that are disturbing and doesn't provide as much value as this could. However at this delay it already becomes a pain for developers to wait for the tests to complete. This commit adds support for the new environment variable HAPROXY_TEST_TIMEOUT that will allow anyone to modify the connect, client and server timeouts. It was set to 5 seconds by default, which should be plenty for quite some time in the CI. All relevant values that were 200ms or above were replaced by this one. A few larger values were left as they are special. One test for the set-timeout action that used to rely on a fixed 1-sec value was extended to a fixed 5-sec, as the timeout is normally not reached, but it needs to be known to compare the old and new values.
2021-11-18 16:46:22 +00:00
timeout connect "${HAPROXY_TEST_TIMEOUT-5s}"
timeout client "${HAPROXY_TEST_TIMEOUT-5s}"
timeout server "${HAPROXY_TEST_TIMEOUT-5s}"
MEDIUM: cli/ssl: configure ssl on server at runtime in the context of a progressive backend migration, we want to be able to activate SSL on outgoing connections to the server at runtime without reloading. This patch adds a `set server ssl` command; in order to allow that: - add `srv_use_ssl` to `show servers state` command for compatibility, also update associated parsing - when using default-server ssl setting, and `no-ssl` on server line, init SSL ctx without activating it - when triggering ssl API, de/activate SSL connections as requested - clean ongoing connections as it is done for addr/port changes, without checking prior server state example config: backend be_foo default-server ssl server srv0 127.0.0.1:6011 weight 1 no-ssl show servers state: 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - -1 where srv0 can switch to ssl later during the runtime: set server be_foo/srv0 ssl on 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - 1 Also update existing tests and create a new one. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2020-11-14 18:25:33 +00:00
frontend myfrontend
bind "fd@${my_fe}"
default_backend test0
backend test0
server www0 ${s1_addr}:${s1_port} no-ssl
BUG/MINOR: server: Don't rely on last default-server to init server SSL context During post-parsing stage, the SSL context of a server is initialized if SSL is configured on the server or its default-server. It is required to be able to enable SSL at runtime. However a regression was introduced, because the last parsed default-server is used. But it is not necessarily the default-server line used to configure the server. This may lead to erroneously initialize the SSL context for a server without SSL parameter or the skip it while it should be done. The problem is the default-server used to configure a server is not saved during configuration parsing. So, the information is lost during the post-parsing. To fix the bug, the SRV_F_DEFSRV_USE_SSL flag is introduced. It is used to know when a server was initialized with a default-server using SSL. For the record, the commit f63704488e ("MEDIUM: cli/ssl: configure ssl on server at runtime") has introduced the bug. This patch must be backported as far as 2.4.
2021-12-01 08:50:41 +00:00
default-server ssl
server www1 ${s1_addr}:${s1_port} no-ssl
MEDIUM: cli/ssl: configure ssl on server at runtime in the context of a progressive backend migration, we want to be able to activate SSL on outgoing connections to the server at runtime without reloading. This patch adds a `set server ssl` command; in order to allow that: - add `srv_use_ssl` to `show servers state` command for compatibility, also update associated parsing - when using default-server ssl setting, and `no-ssl` on server line, init SSL ctx without activating it - when triggering ssl API, de/activate SSL connections as requested - clean ongoing connections as it is done for addr/port changes, without checking prior server state example config: backend be_foo default-server ssl server srv0 127.0.0.1:6011 weight 1 no-ssl show servers state: 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - -1 where srv0 can switch to ssl later during the runtime: set server be_foo/srv0 ssl on 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - 1 Also update existing tests and create a new one. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2020-11-14 18:25:33 +00:00
backend test1
server www0 ${s1_addr}:${s1_port} no-ssl
} -start
haproxy h1 -cli {
# supported case
send "show servers state test0"
BUG/MINOR: server: Don't rely on last default-server to init server SSL context During post-parsing stage, the SSL context of a server is initialized if SSL is configured on the server or its default-server. It is required to be able to enable SSL at runtime. However a regression was introduced, because the last parsed default-server is used. But it is not necessarily the default-server line used to configure the server. This may lead to erroneously initialize the SSL context for a server without SSL parameter or the skip it while it should be done. The problem is the default-server used to configure a server is not saved during configuration parsing. So, the information is lost during the post-parsing. To fix the bug, the SRV_F_DEFSRV_USE_SSL flag is introduced. It is used to know when a server was initialized with a default-server using SSL. For the record, the commit f63704488e ("MEDIUM: cli/ssl: configure ssl on server at runtime") has introduced the bug. This patch must be backported as far as 2.4.
2021-12-01 08:50:41 +00:00
expect ~ "test0 2 www1 ${s1_addr} .* - ${s1_port} - -1"
send "set server test0/www1 ssl on"
MEDIUM: cli/ssl: configure ssl on server at runtime in the context of a progressive backend migration, we want to be able to activate SSL on outgoing connections to the server at runtime without reloading. This patch adds a `set server ssl` command; in order to allow that: - add `srv_use_ssl` to `show servers state` command for compatibility, also update associated parsing - when using default-server ssl setting, and `no-ssl` on server line, init SSL ctx without activating it - when triggering ssl API, de/activate SSL connections as requested - clean ongoing connections as it is done for addr/port changes, without checking prior server state example config: backend be_foo default-server ssl server srv0 127.0.0.1:6011 weight 1 no-ssl show servers state: 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - -1 where srv0 can switch to ssl later during the runtime: set server be_foo/srv0 ssl on 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - 1 Also update existing tests and create a new one. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2020-11-14 18:25:33 +00:00
expect ~ "server ssl setting updated"
send "show servers state test0"
BUG/MINOR: server: Don't rely on last default-server to init server SSL context During post-parsing stage, the SSL context of a server is initialized if SSL is configured on the server or its default-server. It is required to be able to enable SSL at runtime. However a regression was introduced, because the last parsed default-server is used. But it is not necessarily the default-server line used to configure the server. This may lead to erroneously initialize the SSL context for a server without SSL parameter or the skip it while it should be done. The problem is the default-server used to configure a server is not saved during configuration parsing. So, the information is lost during the post-parsing. To fix the bug, the SRV_F_DEFSRV_USE_SSL flag is introduced. It is used to know when a server was initialized with a default-server using SSL. For the record, the commit f63704488e ("MEDIUM: cli/ssl: configure ssl on server at runtime") has introduced the bug. This patch must be backported as far as 2.4.
2021-12-01 08:50:41 +00:00
expect ~ "test0 2 www1 ${s1_addr} .* - ${s1_port} - 1"
send "set server test0/www1 ssl off"
MEDIUM: cli/ssl: configure ssl on server at runtime in the context of a progressive backend migration, we want to be able to activate SSL on outgoing connections to the server at runtime without reloading. This patch adds a `set server ssl` command; in order to allow that: - add `srv_use_ssl` to `show servers state` command for compatibility, also update associated parsing - when using default-server ssl setting, and `no-ssl` on server line, init SSL ctx without activating it - when triggering ssl API, de/activate SSL connections as requested - clean ongoing connections as it is done for addr/port changes, without checking prior server state example config: backend be_foo default-server ssl server srv0 127.0.0.1:6011 weight 1 no-ssl show servers state: 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - -1 where srv0 can switch to ssl later during the runtime: set server be_foo/srv0 ssl on 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - 1 Also update existing tests and create a new one. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2020-11-14 18:25:33 +00:00
expect ~ "server ssl setting updated"
send "show servers state test0"
BUG/MINOR: server: Don't rely on last default-server to init server SSL context During post-parsing stage, the SSL context of a server is initialized if SSL is configured on the server or its default-server. It is required to be able to enable SSL at runtime. However a regression was introduced, because the last parsed default-server is used. But it is not necessarily the default-server line used to configure the server. This may lead to erroneously initialize the SSL context for a server without SSL parameter or the skip it while it should be done. The problem is the default-server used to configure a server is not saved during configuration parsing. So, the information is lost during the post-parsing. To fix the bug, the SRV_F_DEFSRV_USE_SSL flag is introduced. It is used to know when a server was initialized with a default-server using SSL. For the record, the commit f63704488e ("MEDIUM: cli/ssl: configure ssl on server at runtime") has introduced the bug. This patch must be backported as far as 2.4.
2021-12-01 08:50:41 +00:00
expect ~ "test0 2 www1 ${s1_addr} .* - ${s1_port} - 0"
# unsupported cases
send "show servers state test0"
expect ~ "test0 1 www0 ${s1_addr} .* - ${s1_port} - -1"
send "set server test0/www0 ssl on"
expect ~ "'set server <srv> ssl' cannot be set"
MEDIUM: cli/ssl: configure ssl on server at runtime in the context of a progressive backend migration, we want to be able to activate SSL on outgoing connections to the server at runtime without reloading. This patch adds a `set server ssl` command; in order to allow that: - add `srv_use_ssl` to `show servers state` command for compatibility, also update associated parsing - when using default-server ssl setting, and `no-ssl` on server line, init SSL ctx without activating it - when triggering ssl API, de/activate SSL connections as requested - clean ongoing connections as it is done for addr/port changes, without checking prior server state example config: backend be_foo default-server ssl server srv0 127.0.0.1:6011 weight 1 no-ssl show servers state: 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - -1 where srv0 can switch to ssl later during the runtime: set server be_foo/srv0 ssl on 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - 1 Also update existing tests and create a new one. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2020-11-14 18:25:33 +00:00
send "show servers state test1"
expect ~ "test1 1 www0 ${s1_addr} .* - ${s1_port} - -1"
send "set server test1/www0 ssl on"
expect ~ "'set server <srv> ssl' cannot be set"
} -wait