update package config files

Former-commit-id: fd367a91cc0feb22b67f034627d59feb679b81e8

pkg/deb/conf/sentinel.conf

@@ -20,12 +20,12 @@
 # The port that this sentinel instance will run on
 port 26379
 
-# By default Redis Sentinel does not run as a daemon. Use 'yes' if you need it.
+# By default KeyDB Sentinel does not run as a daemon. Use 'yes' if you need it.
-# Note that Redis will write a pid file in /var/run/keydb-sentinel.pid when
+# Note that KeyDB will write a pid file in /var/run/keydb-sentinel.pid when
 # daemonized.
 daemonize yes
 
-# When running daemonized, Redis Sentinel writes a pid file in
+# When running daemonized, KeyDB Sentinel writes a pid file in
 # /var/run/keydb-sentinel.pid by default. You can specify a custom pid file
 # location here.
 pidfile /var/run/sentinel/keydb-sentinel.pid
@@ -59,7 +59,7 @@ logfile /var/log/keydb/keydb-sentinel.log
 
 # dir <working-directory>
 # Every long running process should have a well-defined working directory.
-# For Redis Sentinel to chdir to /tmp at startup is the simplest thing
+# For KeyDB Sentinel to chdir to /tmp at startup is the simplest thing
 # for the process to don't interfere with administrative tasks such as
 # unmounting filesystems.
 dir /var/lib/keydb
@@ -86,22 +86,34 @@ sentinel monitor mymaster 127.0.0.1 6379 2
 # sentinel auth-pass <master-name> <password>
 #
 # Set the password to use to authenticate with the master and replicas.
-# Useful if there is a password set in the Redis instances to monitor.
+# Useful if there is a password set in the KeyDB instances to monitor.
 #
 # Note that the master password is also used for replicas, so it is not
 # possible to set a different password in masters and replicas instances
 # if you want to be able to monitor these instances with Sentinel.
 #
-# However you can have Redis instances without the authentication enabled
+# However you can have KeyDB instances without the authentication enabled
-# mixed with Redis instances requiring the authentication (as long as the
+# mixed with KeyDB instances requiring the authentication (as long as the
 # password set is the same for all the instances requiring the password) as
-# the AUTH command will have no effect in Redis instances with authentication
+# the AUTH command will have no effect in KeyDB instances with authentication
 # switched off.
 #
 # Example:
 #
 # sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
 
+# sentinel auth-user <master-name> <username>
+#
+# This is useful in order to authenticate to instances having ACL capabilities,
+# that is, running KeyDB 6.0 or greater. When just auth-pass is provided the
+# Sentinel instance will authenticate to KeyDB using the old "AUTH <pass>"
+# method. When also an username is provided, it will use "AUTH <user> <pass>".
+# In the KeyDB servers side, the ACL to provide just minimal access to
+# Sentinel instances, should be configured along the following lines:
+#
+#     user sentinel-user >somepassword +client +subscribe +publish \
+#                        +ping +info +multi +slaveof +config +client +exec on
+
 # sentinel down-after-milliseconds <master-name> <milliseconds>
 #
 # Number of milliseconds the master (or any attached replica or sentinel) should
@@ -112,6 +124,73 @@ sentinel monitor mymaster 127.0.0.1 6379 2
 # Default is 30 seconds.
 sentinel down-after-milliseconds mymaster 30000
 
+# IMPORTANT NOTE: starting with KeyDB 6.2 ACL capability is supported for
+# Sentinel mode, please refer to the Redis website https://redis.io/topics/acl
+# for more details.
+
+# Sentinel's ACL users are defined in the following format:
+#
+#   user <username> ... acl rules ...
+#
+# For example:
+#
+#   user worker +@admin +@connection ~* on >ffa9203c493aa99
+#
+# For more information about ACL configuration please refer to the Redis
+# website at https://redis.io/topics/acl and KeyDB server configuration 
+# template keydb.conf.
+
+# ACL LOG
+#
+# The ACL Log tracks failed commands and authentication events associated
+# with ACLs. The ACL Log is useful to troubleshoot failed commands blocked 
+# by ACLs. The ACL Log is stored in memory. You can reclaim memory with 
+# ACL LOG RESET. Define the maximum entry length of the ACL Log below.
+acllog-max-len 128
+
+# Using an external ACL file
+#
+# Instead of configuring users here in this file, it is possible to use
+# a stand-alone file just listing users. The two methods cannot be mixed:
+# if you configure users here and at the same time you activate the external
+# ACL file, the server will refuse to start.
+#
+# The format of the external ACL user file is exactly the same as the
+# format that is used inside keydb.conf to describe users.
+#
+# aclfile /etc/keydb/sentinel-users.acl
+
+# requirepass <password>
+#
+# You can configure Sentinel itself to require a password, however when doing
+# so Sentinel will try to authenticate with the same password to all the
+# other Sentinels. So you need to configure all your Sentinels in a given
+# group with the same "requirepass" password. Check the following documentation
+# for more info: https://redis.io/topics/sentinel
+#
+# IMPORTANT NOTE: starting with KeyDB 6.2 "requirepass" is a compatibility
+# layer on top of the ACL system. The option effect will be just setting
+# the password for the default user. Clients will still authenticate using
+# AUTH <password> as usually, or more explicitly with AUTH default <password>
+# if they follow the new protocol: both will work.
+#
+# New config files are advised to use separate authentication control for
+# incoming connections (via ACL), and for outgoing connections (via
+# sentinel-user and sentinel-pass) 
+#
+# The requirepass is not compatable with aclfile option and the ACL LOAD
+# command, these will cause requirepass to be ignored.
+
+# sentinel sentinel-user <username>
+#
+# You can configure Sentinel to authenticate with other Sentinels with specific
+# user name. 
+
+# sentinel sentinel-pass <password>
+#
+# The password for Sentinel to authenticate with other Sentinels. If sentinel-user
+# is not configured, Sentinel will use 'default' user with sentinel-pass to authenticate.
+
 # sentinel parallel-syncs <master-name> <numreplicas>
 #
 # How many replicas we can reconfigure to point to the new replica simultaneously
@@ -172,7 +251,7 @@ sentinel failover-timeout mymaster 180000
 # generated in the WARNING level (for instance -sdown, -odown, and so forth).
 # This script should notify the system administrator via email, SMS, or any
 # other messaging system, that there is something wrong with the monitored
-# Redis systems.
+# KeyDB systems.
 #
 # The script is called with just two arguments: the first is the event type
 # and the second the event description.
@@ -182,7 +261,7 @@ sentinel failover-timeout mymaster 180000
 #
 # Example:
 #
-# sentinel notification-script mymaster /var/redis/notify.sh
+# sentinel notification-script mymaster /var/keydb/notify.sh
 
 # CLIENTS RECONFIGURATION SCRIPT
 #
@@ -207,7 +286,7 @@ sentinel failover-timeout mymaster 180000
 #
 # Example:
 #
-# sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
+# sentinel client-reconfig-script mymaster /var/keydb/reconfig.sh
 
 # SECURITY
 #
@@ -218,11 +297,11 @@ sentinel failover-timeout mymaster 180000
 
 sentinel deny-scripts-reconfig yes
 
-# REDIS COMMANDS RENAMING
+# KEYDB COMMANDS RENAMING
 #
-# Sometimes the Redis server has certain commands, that are needed for Sentinel
+# Sometimes the KeyDB server has certain commands, that are needed for Sentinel
 # to work correctly, renamed to unguessable strings. This is often the case
-# of CONFIG and SLAVEOF in the context of providers that provide Redis as
+# of CONFIG and SLAVEOF in the context of providers that provide KeyDB as
 # a service, and don't want the customers to reconfigure the instances outside
 # of the administration console.
 #
@@ -239,6 +318,24 @@ sentinel deny-scripts-reconfig yes
 # SENTINEL SET can also be used in order to perform this configuration at runtime.
 #
 # In order to set a command back to its original name (undo the renaming), it
-# is possible to just rename a command to itsef:
+# is possible to just rename a command to itself:
 #
 # SENTINEL rename-command mymaster CONFIG CONFIG
+
+# HOSTNAMES SUPPORT
+#
+# Normally Sentinel uses only IP addresses and requires SENTINEL MONITOR
+# to specify an IP address. Also, it requires the KeyDB replica-announce-ip
+# keyword to specify only IP addresses.
+#
+# You may enable hostnames support by enabling resolve-hostnames. Note
+# that you must make sure your DNS is configured properly and that DNS
+# resolution does not introduce very long delays.
+#
+SENTINEL resolve-hostnames no
+
+# When resolve-hostnames is enabled, Sentinel still uses IP addresses
+# when exposing instances to users, configuration files, etc. If you want
+# to retain the hostnames when announced, enable announce-hostnames below.
+#
+SENTINEL announce-hostnames no

pkg/rpm/keydb_build/keydb_rpm/etc/keydb/sentinel.conf

@@ -20,20 +20,20 @@
 # The port that this sentinel instance will run on
 port 26379
 
-# By default Redis Sentinel does not run as a daemon. Use 'yes' if you need it.
+# By default KeyDB Sentinel does not run as a daemon. Use 'yes' if you need it.
-# Note that Redis will write a pid file in /var/run/redis-sentinel.pid when
+# Note that KeyDB will write a pid file in /var/run/keydb-sentinel.pid when
 # daemonized.
 daemonize no
 
-# When running daemonized, Redis Sentinel writes a pid file in
+# When running daemonized, KeyDB Sentinel writes a pid file in
-# /var/run/redis-sentinel.pid by default. You can specify a custom pid file
+# /var/run/keydb-sentinel.pid by default. You can specify a custom pid file
 # location here.
-pidfile /var/run/redis-sentinel.pid
+pidfile /var/run/sentinel/keydb-sentinel.pid
 
 # Specify the log file name. Also the empty string can be used to force
 # Sentinel to log on the standard output. Note that if you use standard
 # output for logging but daemonize, logs will be sent to /dev/null
-logfile /var/log/redis/sentinel.log
+logfile /var/log/keydb/keydb-sentinel.log
 
 # sentinel announce-ip <ip>
 # sentinel announce-port <port>
@@ -59,12 +59,12 @@ logfile /var/log/redis/sentinel.log
 
 # dir <working-directory>
 # Every long running process should have a well-defined working directory.
-# For Redis Sentinel to chdir to /tmp at startup is the simplest thing
+# For KeyDB Sentinel to chdir to /tmp at startup is the simplest thing
 # for the process to don't interfere with administrative tasks such as
 # unmounting filesystems.
 dir /tmp
 
-# sentinel monitor <master-name> <ip> <redis-port> <quorum>
+# sentinel monitor <master-name> <ip> <keydb-port> <quorum>
 #
 # Tells Sentinel to monitor this master, and to consider it in O_DOWN
 # (Objectively Down) state only if at least <quorum> sentinels agree.
@@ -86,22 +86,34 @@ sentinel monitor mymaster 127.0.0.1 6379 2
 # sentinel auth-pass <master-name> <password>
 #
 # Set the password to use to authenticate with the master and replicas.
-# Useful if there is a password set in the Redis instances to monitor.
+# Useful if there is a password set in the KeyDB instances to monitor.
 #
 # Note that the master password is also used for replicas, so it is not
 # possible to set a different password in masters and replicas instances
 # if you want to be able to monitor these instances with Sentinel.
 #
-# However you can have Redis instances without the authentication enabled
+# However you can have KeyDB instances without the authentication enabled
-# mixed with Redis instances requiring the authentication (as long as the
+# mixed with KeyDB instances requiring the authentication (as long as the
 # password set is the same for all the instances requiring the password) as
-# the AUTH command will have no effect in Redis instances with authentication
+# the AUTH command will have no effect in KeyDB instances with authentication
 # switched off.
 #
 # Example:
 #
 # sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
 
+# sentinel auth-user <master-name> <username>
+#
+# This is useful in order to authenticate to instances having ACL capabilities,
+# that is, running KeyDB 6.0 or greater. When just auth-pass is provided the
+# Sentinel instance will authenticate to KeyDB using the old "AUTH <pass>"
+# method. When also an username is provided, it will use "AUTH <user> <pass>".
+# In the KeyDB servers side, the ACL to provide just minimal access to
+# Sentinel instances, should be configured along the following lines:
+#
+#     user sentinel-user >somepassword +client +subscribe +publish \
+#                        +ping +info +multi +slaveof +config +client +exec on
+
 # sentinel down-after-milliseconds <master-name> <milliseconds>
 #
 # Number of milliseconds the master (or any attached replica or sentinel) should
@@ -112,6 +124,73 @@ sentinel monitor mymaster 127.0.0.1 6379 2
 # Default is 30 seconds.
 sentinel down-after-milliseconds mymaster 30000
 
+# IMPORTANT NOTE: starting with KeyDB 6.2 ACL capability is supported for
+# Sentinel mode, please refer to the Redis website https://redis.io/topics/acl
+# for more details.
+
+# Sentinel's ACL users are defined in the following format:
+#
+#   user <username> ... acl rules ...
+#
+# For example:
+#
+#   user worker +@admin +@connection ~* on >ffa9203c493aa99
+#
+# For more information about ACL configuration please refer to the Redis
+# website at https://redis.io/topics/acl and KeyDB server configuration 
+# template keydb.conf.
+
+# ACL LOG
+#
+# The ACL Log tracks failed commands and authentication events associated
+# with ACLs. The ACL Log is useful to troubleshoot failed commands blocked 
+# by ACLs. The ACL Log is stored in memory. You can reclaim memory with 
+# ACL LOG RESET. Define the maximum entry length of the ACL Log below.
+acllog-max-len 128
+
+# Using an external ACL file
+#
+# Instead of configuring users here in this file, it is possible to use
+# a stand-alone file just listing users. The two methods cannot be mixed:
+# if you configure users here and at the same time you activate the external
+# ACL file, the server will refuse to start.
+#
+# The format of the external ACL user file is exactly the same as the
+# format that is used inside keydb.conf to describe users.
+#
+# aclfile /etc/keydb/sentinel-users.acl
+
+# requirepass <password>
+#
+# You can configure Sentinel itself to require a password, however when doing
+# so Sentinel will try to authenticate with the same password to all the
+# other Sentinels. So you need to configure all your Sentinels in a given
+# group with the same "requirepass" password. Check the following documentation
+# for more info: https://redis.io/topics/sentinel
+#
+# IMPORTANT NOTE: starting with KeyDB 6.2 "requirepass" is a compatibility
+# layer on top of the ACL system. The option effect will be just setting
+# the password for the default user. Clients will still authenticate using
+# AUTH <password> as usually, or more explicitly with AUTH default <password>
+# if they follow the new protocol: both will work.
+#
+# New config files are advised to use separate authentication control for
+# incoming connections (via ACL), and for outgoing connections (via
+# sentinel-user and sentinel-pass) 
+#
+# The requirepass is not compatable with aclfile option and the ACL LOAD
+# command, these will cause requirepass to be ignored.
+
+# sentinel sentinel-user <username>
+#
+# You can configure Sentinel to authenticate with other Sentinels with specific
+# user name. 
+
+# sentinel sentinel-pass <password>
+#
+# The password for Sentinel to authenticate with other Sentinels. If sentinel-user
+# is not configured, Sentinel will use 'default' user with sentinel-pass to authenticate.
+
 # sentinel parallel-syncs <master-name> <numreplicas>
 #
 # How many replicas we can reconfigure to point to the new replica simultaneously
@@ -172,7 +251,7 @@ sentinel failover-timeout mymaster 180000
 # generated in the WARNING level (for instance -sdown, -odown, and so forth).
 # This script should notify the system administrator via email, SMS, or any
 # other messaging system, that there is something wrong with the monitored
-# Redis systems.
+# KeyDB systems.
 #
 # The script is called with just two arguments: the first is the event type
 # and the second the event description.
@@ -182,7 +261,7 @@ sentinel failover-timeout mymaster 180000
 #
 # Example:
 #
-# sentinel notification-script mymaster /var/redis/notify.sh
+# sentinel notification-script mymaster /var/keydb/notify.sh
 
 # CLIENTS RECONFIGURATION SCRIPT
 #
@@ -207,7 +286,7 @@ sentinel failover-timeout mymaster 180000
 #
 # Example:
 #
-# sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
+# sentinel client-reconfig-script mymaster /var/keydb/reconfig.sh
 
 # SECURITY
 #
@@ -218,11 +297,11 @@ sentinel failover-timeout mymaster 180000
 
 sentinel deny-scripts-reconfig yes
 
-# REDIS COMMANDS RENAMING
+# KEYDB COMMANDS RENAMING
 #
-# Sometimes the Redis server has certain commands, that are needed for Sentinel
+# Sometimes the KeyDB server has certain commands, that are needed for Sentinel
 # to work correctly, renamed to unguessable strings. This is often the case
-# of CONFIG and SLAVEOF in the context of providers that provide Redis as
+# of CONFIG and SLAVEOF in the context of providers that provide KeyDB as
 # a service, and don't want the customers to reconfigure the instances outside
 # of the administration console.
 #
@@ -239,6 +318,24 @@ sentinel deny-scripts-reconfig yes
 # SENTINEL SET can also be used in order to perform this configuration at runtime.
 #
 # In order to set a command back to its original name (undo the renaming), it
-# is possible to just rename a command to itsef:
+# is possible to just rename a command to itself:
 #
 # SENTINEL rename-command mymaster CONFIG CONFIG
+
+# HOSTNAMES SUPPORT
+#
+# Normally Sentinel uses only IP addresses and requires SENTINEL MONITOR
+# to specify an IP address. Also, it requires the KeyDB replica-announce-ip
+# keyword to specify only IP addresses.
+#
+# You may enable hostnames support by enabling resolve-hostnames. Note
+# that you must make sure your DNS is configured properly and that DNS
+# resolution does not introduce very long delays.
+#
+SENTINEL resolve-hostnames no
+
+# When resolve-hostnames is enabled, Sentinel still uses IP addresses
+# when exposing instances to users, configuration files, etc. If you want
+# to retain the hostnames when announced, enable announce-hostnames below.
+#
+SENTINEL announce-hostnames no