- 29 Jul, 2020 1 commit
-
-
namtsui authored
The Redis sentinel would crash with a segfault after a few minutes because it tried to read from a page without read permissions. Check up front whether the sds is long enough to contain redis:slave or redis:master before memcmp() as is done everywhere else in sentinelRefreshInstanceInfo(). Bug report and commit message from Theo Buehler. Fix from Nam Nguyen. Co-authored-by:
Nam Nguyen <namn@berkeley.edu>
-
- 22 Jun, 2020 1 commit
-
-
hwware authored
-
- 20 Apr, 2020 1 commit
-
-
antirez authored
Related to #7113.
-
- 17 Apr, 2020 1 commit
-
-
omg-by authored
when trigger a always fail scripts, sentinel.running_scripts will increase ten times, however it only decrease one times onretry the maximum. and it will't reset, when it become SENTINEL_SCRIPT_MAX_RUNNING, sentinel don't trigger scripts.
-
- 16 Mar, 2020 2 commits
- 07 Jan, 2020 1 commit
-
-
yz1509 authored
-
- 17 Dec, 2019 1 commit
-
-
Madelyn Olson authored
-
- 19 Nov, 2019 1 commit
-
-
antirez authored
-
- 07 Nov, 2019 1 commit
-
-
Patrick Valsecchi authored
When a redis instance becomes a slave, sentinel also kills pubsub clients. Closes #6545
-
- 15 Oct, 2019 1 commit
-
-
Yossi Gottlieb authored
-
- 07 Oct, 2019 2 commits
-
-
Yossi Gottlieb authored
Add configuration options for TLS protocol versions, ciphers/cipher suites selection, etc.
-
Yossi Gottlieb authored
* Introduce a connection abstraction layer for all socket operations and integrate it across the code base. * Provide an optional TLS connections implementation based on OpenSSL. * Pull a newer version of hiredis with TLS support. * Tests, redis-cli updates for TLS support.
-
- 27 Feb, 2019 2 commits
-
-
vattezhang authored
-
vattezhang authored
-
- 18 Jan, 2019 1 commit
-
-
antirez authored
-
- 09 Jan, 2019 3 commits
- 31 Oct, 2018 2 commits
-
-
antirez authored
So far it was not possible to setup Sentinel with authentication enabled. This commit introduces this feature: every Sentinel will try to authenticate with other sentinels using the same password it is configured to accept clients with. So for instance if a Sentinel has a "requirepass" configuration statemnet set to "foo", it will use the "foo" password to authenticate with every other Sentinel it connects to. So basically to add the "requirepass" to all the Sentinels configurations is enough in order to make sure that: 1) Clients will require the password to access the Sentinels instances. 2) Each Sentinel will use the same password to connect and authenticate with every other Sentinel in the group. Related to #3279 and #3329.
-
antirez authored
Sentinel must be exposed, so protected mode is just an issue for users in case Redis was started in Sentinel mode. Related to #3279 and #3329.
-
- 11 Sep, 2018 1 commit
-
-
antirez authored
SENTINEL REPLICAS was added as an alias, in the configuration rewriting now it uses known-replica, however all the rest is basically at API level of logged events and messages having to do with the protocol, so there is very little to do here compared to the Redis core itself, to preserve compatibility.
-
- 26 Aug, 2018 1 commit
-
-
Chris Lamb authored
-
- 03 Jul, 2018 1 commit
-
-
Jack Drogon authored
-
- 28 Jun, 2018 1 commit
-
-
zhaozhao.zz authored
-
- 27 Jun, 2018 1 commit
-
-
shenlongxing authored
-
- 26 Jun, 2018 1 commit
-
-
antirez authored
Thanks to @shenlongxing for reporting the problem. Related to #5062.
-
- 25 Jun, 2018 9 commits
-
-
antirez authored
Instead of telling the user to set the renamed command to "" to remove the renaming, to the obvious thing when a command is renamed to itself. So if I want to remove the renaming of PING, I just rename it to PING again.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
- 14 Jun, 2018 1 commit
-
-
antirez authored
The ability of "SENTINEL SET" to change the reconfiguration script at runtime is a problem even in the security model of Redis: any client inside the network may set any executable to be ran once a failover is triggered. This option adds protection for this problem: by default the two SENTINEL SET subcommands modifying scripts paths are denied. However the user is still able to rever that using the Sentinel configuration file in order to allow such a feature.
-
- 23 May, 2018 1 commit
-
-
antirez authored
See issue #2819 for details. The gist is that when we want to send INFO because we are over the time, we used to send only INFO commands, no longer sending PING commands. However if a master fails exactly when we are about to send an INFO command, the PING times will result zero because the PONG reply was already received, and we'll fail to send more PINGs, since we try only to send INFO commands: the failure detector will delay until the connection is closed and re-opened for "long timeout". This commit changes the logic so that we can send the three kind of messages regardless of the fact we sent another one already in the same code path. It could happen that we go over the message limit for the link by a few messages, but this is not significant. However now we'll not introduce delays in sending commands just because there was something else to send at the same time.
-
- 20 Feb, 2017 1 commit
-
-
antirez authored
This change attempts to switch to an hash function which mitigates the effects of the HashDoS attack (denial of service attack trying to force data structures to worst case behavior) while at the same time providing Redis with an hash function that does not expect the input data to be word aligned, a condition no longer true now that sds.c strings have a varialbe length header. Note that it is possible sometimes that even using an hash function for which collisions cannot be generated without knowing the seed, special implementation details or the exposure of the seed in an indirect way (for example the ability to add elements to a Set and check the return in which Redis returns them with SMEMBERS) may make the attacker's life simpler in the process of trying to guess the correct seed, however the next step would be to switch to a log(N) data structure when too many items in a single bucket are detected: this seems like an overkill in the case of Redis. SPEED REGRESION TESTS: In order to verify that switching from MurmurHash to SipHash had no impact on speed, a set of benchmarks involving fast insertion of 5 million of keys were performed. The result shows Redis with SipHash in high pipelining conditions to be about 4% slower compared to using the previous hash function. However this could partially be related to the fact that the current implementation does not attempt to hash whole words at a time but reads single bytes, in order to have an output which is endian-netural and at the same time working on systems where unaligned memory accesses are a problem. Further X86 specific optimizations should be tested, the function may easily get at the same level of MurMurHash2 if a few optimizations are performed.
-
- 14 Sep, 2016 1 commit
-
-
antirez authored
-