513 lines
24 KiB
Django/Jinja
513 lines
24 KiB
Django/Jinja
{{ ansible_managed | comment }}
|
|
|
|
# Only listen on localhost
|
|
bind 127.0.0.1 -::1
|
|
|
|
# When protected mode is on and the default user has no password, the server
|
|
# only accepts local connections from the IPv4 address (127.0.0.1), IPv6 address
|
|
# (::1) or Unix domain sockets.
|
|
protected-mode yes
|
|
|
|
# Redis uses default hardened security configuration directives to reduce the
|
|
# attack surface on innocent users. Therefore, several sensitive configuration
|
|
# directives are immutable, and some potentially-dangerous commands are blocked.
|
|
#
|
|
# Configuration directives that control files that Redis writes to (e.g., 'dir'
|
|
# and 'dbfilename') and that aren't usually modified during runtime
|
|
# are protected by making them immutable.
|
|
#
|
|
# Commands that can increase the attack surface of Redis and that aren't usually
|
|
# called by users are blocked by default.
|
|
#
|
|
# These can be exposed to either all connections or just local ones by setting
|
|
# each of the configs listed below to either of these values:
|
|
#
|
|
# no - Block for any connection (remain immutable)
|
|
# yes - Allow for any connection (no protection)
|
|
# local - Allow only for local connections. Ones originating from the
|
|
# IPv4 address (127.0.0.1), IPv6 address (::1) or Unix domain sockets.
|
|
enable-protected-configs no
|
|
enable-debug-command no
|
|
enable-module-command no
|
|
|
|
# Accept connections on the specified port, default is 6379 (IANA #815344).
|
|
# If port 0 is specified Redis will not listen on a TCP socket.
|
|
port 0
|
|
|
|
# Unix socket.
|
|
unixsocket /run/redis/redis.sock
|
|
unixsocketperm 777
|
|
|
|
# Close the connection after a client is idle for N seconds (0 to disable)
|
|
timeout 0
|
|
|
|
# Apply OS-specific mechanism to mark the listening socket with the specified
|
|
# ID, to support advanced routing and filtering capabilities.
|
|
#
|
|
# On Linux, the ID represents a connection mark.
|
|
# On FreeBSD, the ID represents a socket cookie ID.
|
|
# On OpenBSD, the ID represents a route table ID.
|
|
#
|
|
# The default value is 0, which implies no marking is required.
|
|
# socket-mark-id 0
|
|
|
|
################################# GENERAL #####################################
|
|
|
|
# By default Redis does not run as a daemon. Use 'yes' if you need it.
|
|
# Note that Redis will write a pid file in /var/run/redis.pid when daemonized.
|
|
# When Redis is supervised by upstart or systemd, this parameter has no impact.
|
|
daemonize no
|
|
|
|
# If you run Redis from upstart or systemd, Redis can interact with your
|
|
# supervision tree. Options:
|
|
# supervised no - no supervision interaction
|
|
# supervised upstart - signal upstart by putting Redis into SIGSTOP mode
|
|
# requires "expect stop" in your upstart job config
|
|
# supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET
|
|
# on startup, and updating Redis status on a regular
|
|
# basis.
|
|
# supervised auto - detect upstart or systemd method based on
|
|
# UPSTART_JOB or NOTIFY_SOCKET environment variables
|
|
# Note: these supervision methods only signal "process is ready."
|
|
# They do not enable continuous pings back to your supervisor.
|
|
#
|
|
# The default is "no". To run under upstart/systemd, you can simply uncomment
|
|
# the line below:
|
|
supervised auto
|
|
|
|
pidfile /run/redis_6379.pid
|
|
|
|
# Specify the server verbosity level.
|
|
# This can be one of:
|
|
# debug (a lot of information, useful for development/testing)
|
|
# verbose (many rarely useful info, but not a mess like the debug level)
|
|
# notice (moderately verbose, what you want in production probably)
|
|
# warning (only very important / critical messages are logged)
|
|
# nothing (nothing is logged)
|
|
loglevel notice
|
|
|
|
# Specify the log file name. Also the empty string can be used to force
|
|
# Redis 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 ""
|
|
|
|
# Set the number of databases. The default database is DB 0, you can select
|
|
# a different one on a per-connection basis using SELECT <dbid> where
|
|
# dbid is a number between 0 and 'databases'-1
|
|
databases 16
|
|
|
|
# Set the local environment which is used for string comparison operations, and
|
|
# also affect the performance of Lua scripts. Empty String indicates the locale
|
|
# is derived from the environment variables.
|
|
locale-collate ""
|
|
|
|
################################ SNAPSHOTTING ################################
|
|
|
|
# Save the DB to disk.
|
|
#
|
|
# save <seconds> <changes> [<seconds> <changes> ...]
|
|
#
|
|
# Redis will save the DB if the given number of seconds elapsed and it
|
|
# surpassed the given number of write operations against the DB.
|
|
#
|
|
# Snapshotting can be completely disabled with a single empty string argument
|
|
# as in following example:
|
|
#
|
|
# save ""
|
|
#
|
|
# Unless specified otherwise, by default Redis will save the DB:
|
|
# * After 3600 seconds (an hour) if at least 1 change was performed
|
|
# * After 300 seconds (5 minutes) if at least 100 changes were performed
|
|
# * After 60 seconds if at least 10000 changes were performed
|
|
#
|
|
# You can set these explicitly by uncommenting the following line.
|
|
#
|
|
save 3600 1 300 100 60 10000
|
|
|
|
# By default Redis will stop accepting writes if RDB snapshots are enabled
|
|
# (at least one save point) and the latest background save failed.
|
|
# This will make the user aware (in a hard way) that data is not persisting
|
|
# on disk properly, otherwise chances are that no one will notice and some
|
|
# disaster will happen.
|
|
#
|
|
# If the background saving process will start working again Redis will
|
|
# automatically allow writes again.
|
|
#
|
|
# However if you have setup your proper monitoring of the Redis server
|
|
# and persistence, you may want to disable this feature so that Redis will
|
|
# continue to work as usual even if there are problems with disk,
|
|
# permissions, and so forth.
|
|
stop-writes-on-bgsave-error yes
|
|
|
|
# Compress string objects using LZF when dump .rdb databases?
|
|
# By default compression is enabled as it's almost always a win.
|
|
# If you want to save some CPU in the saving child set it to 'no' but
|
|
# the dataset will likely be bigger if you have compressible values or keys.
|
|
rdbcompression yes
|
|
|
|
# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
|
|
# This makes the format more resistant to corruption but there is a performance
|
|
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
|
|
# for maximum performances.
|
|
#
|
|
# RDB files created with checksum disabled have a checksum of zero that will
|
|
# tell the loading code to skip the check.
|
|
rdbchecksum yes
|
|
|
|
# Enables or disables full sanitization checks for ziplist and listpack etc when
|
|
# loading an RDB or RESTORE payload. This reduces the chances of a assertion or
|
|
# crash later on while processing commands.
|
|
# Options:
|
|
# no - Never perform full sanitization
|
|
# yes - Always perform full sanitization
|
|
# clients - Perform full sanitization only for user connections.
|
|
# Excludes: RDB files, RESTORE commands received from the master
|
|
# connection, and client connections which have the
|
|
# skip-sanitize-payload ACL flag.
|
|
# The default should be 'clients' but since it currently affects cluster
|
|
# resharding via MIGRATE, it is temporarily set to 'no' by default.
|
|
#
|
|
sanitize-dump-payload clients
|
|
|
|
# The filename where to dump the DB
|
|
dbfilename dump.rdb
|
|
|
|
# The working directory.
|
|
#
|
|
# The DB will be written inside this directory, with the filename specified
|
|
# above using the 'dbfilename' configuration directive.
|
|
#
|
|
# The Append Only File will also be created inside this directory.
|
|
dir /data
|
|
|
|
################################## SECURITY ###################################
|
|
|
|
# Warning: since Redis is pretty fast, an outside user can try up to
|
|
# 1 million passwords per second against a modern box. This means that you
|
|
# should use very strong passwords, otherwise they will be very easy to break.
|
|
# Note that because the password is really a shared secret between the client
|
|
# and the server, and should not be memorized by any human, the password
|
|
# can be easily a long string from /dev/urandom or whatever, so by using a
|
|
# long and unguessable password no brute force attack will be possible.
|
|
|
|
# Redis ACL users are defined in the following format:
|
|
#
|
|
# user <username> ... acl rules ...
|
|
#
|
|
# For example:
|
|
#
|
|
# user worker +@list +@connection ~jobs:* on >ffa9203c493aa99
|
|
#
|
|
# The special username "default" is used for new connections. If this user
|
|
# has the "nopass" rule, then new connections will be immediately authenticated
|
|
# as the "default" user without the need of any password provided via the
|
|
# AUTH command. Otherwise if the "default" user is not flagged with "nopass"
|
|
# the connections will start in not authenticated state, and will require
|
|
# AUTH (or the HELLO command AUTH option) in order to be authenticated and
|
|
# start to work.
|
|
#
|
|
# The ACL rules that describe what a user can do are the following:
|
|
#
|
|
# on Enable the user: it is possible to authenticate as this user.
|
|
# off Disable the user: it's no longer possible to authenticate
|
|
# with this user, however the already authenticated connections
|
|
# will still work.
|
|
# skip-sanitize-payload RESTORE dump-payload sanitization is skipped.
|
|
# sanitize-payload RESTORE dump-payload is sanitized (default).
|
|
# +<command> Allow the execution of that command.
|
|
# May be used with `|` for allowing subcommands (e.g "+config|get")
|
|
# -<command> Disallow the execution of that command.
|
|
# May be used with `|` for blocking subcommands (e.g "-config|set")
|
|
# +@<category> Allow the execution of all the commands in such category
|
|
# with valid categories are like @admin, @set, @sortedset, ...
|
|
# and so forth, see the full list in the server.c file where
|
|
# the Redis command table is described and defined.
|
|
# The special category @all means all the commands, but currently
|
|
# present in the server, and that will be loaded in the future
|
|
# via modules.
|
|
# +<command>|first-arg Allow a specific first argument of an otherwise
|
|
# disabled command. It is only supported on commands with
|
|
# no sub-commands, and is not allowed as negative form
|
|
# like -SELECT|1, only additive starting with "+". This
|
|
# feature is deprecated and may be removed in the future.
|
|
# allcommands Alias for +@all. Note that it implies the ability to execute
|
|
# all the future commands loaded via the modules system.
|
|
# nocommands Alias for -@all.
|
|
# ~<pattern> Add a pattern of keys that can be mentioned as part of
|
|
# commands. For instance ~* allows all the keys. The pattern
|
|
# is a glob-style pattern like the one of KEYS.
|
|
# It is possible to specify multiple patterns.
|
|
# %R~<pattern> Add key read pattern that specifies which keys can be read
|
|
# from.
|
|
# %W~<pattern> Add key write pattern that specifies which keys can be
|
|
# written to.
|
|
# allkeys Alias for ~*
|
|
# resetkeys Flush the list of allowed keys patterns.
|
|
# &<pattern> Add a glob-style pattern of Pub/Sub channels that can be
|
|
# accessed by the user. It is possible to specify multiple channel
|
|
# patterns.
|
|
# allchannels Alias for &*
|
|
# resetchannels Flush the list of allowed channel patterns.
|
|
# ><password> Add this password to the list of valid password for the user.
|
|
# For example >mypass will add "mypass" to the list.
|
|
# This directive clears the "nopass" flag (see later).
|
|
# <<password> Remove this password from the list of valid passwords.
|
|
# nopass All the set passwords of the user are removed, and the user
|
|
# is flagged as requiring no password: it means that every
|
|
# password will work against this user. If this directive is
|
|
# used for the default user, every new connection will be
|
|
# immediately authenticated with the default user without
|
|
# any explicit AUTH command required. Note that the "resetpass"
|
|
# directive will clear this condition.
|
|
# resetpass Flush the list of allowed passwords. Moreover removes the
|
|
# "nopass" status. After "resetpass" the user has no associated
|
|
# passwords and there is no way to authenticate without adding
|
|
# some password (or setting it as "nopass" later).
|
|
# reset Performs the following actions: resetpass, resetkeys, resetchannels,
|
|
# allchannels (if acl-pubsub-default is set), off, clearselectors, -@all.
|
|
# The user returns to the same state it has immediately after its creation.
|
|
# (<options>) Create a new selector with the options specified within the
|
|
# parentheses and attach it to the user. Each option should be
|
|
# space separated. The first character must be ( and the last
|
|
# character must be ).
|
|
# clearselectors Remove all of the currently attached selectors.
|
|
# Note this does not change the "root" user permissions,
|
|
# which are the permissions directly applied onto the
|
|
# user (outside the parentheses).
|
|
#
|
|
# ACL rules can be specified in any order: for instance you can start with
|
|
# passwords, then flags, or key patterns. However note that the additive
|
|
# and subtractive rules will CHANGE MEANING depending on the ordering.
|
|
# For instance see the following example:
|
|
#
|
|
# user alice on +@all -DEBUG ~* >somepassword
|
|
#
|
|
# This will allow "alice" to use all the commands with the exception of the
|
|
# DEBUG command, since +@all added all the commands to the set of the commands
|
|
# alice can use, and later DEBUG was removed. However if we invert the order
|
|
# of two ACL rules the result will be different:
|
|
#
|
|
# user alice on -DEBUG +@all ~* >somepassword
|
|
#
|
|
# Now DEBUG was removed when alice had yet no commands in the set of allowed
|
|
# commands, later all the commands are added, so the user will be able to
|
|
# execute everything.
|
|
#
|
|
# Basically ACL rules are processed left-to-right.
|
|
#
|
|
# The following is a list of command categories and their meanings:
|
|
# * keyspace - Writing or reading from keys, databases, or their metadata
|
|
# in a type agnostic way. Includes DEL, RESTORE, DUMP, RENAME, EXISTS, DBSIZE,
|
|
# KEYS, EXPIRE, TTL, FLUSHALL, etc. Commands that may modify the keyspace,
|
|
# key or metadata will also have `write` category. Commands that only read
|
|
# the keyspace, key or metadata will have the `read` category.
|
|
# * read - Reading from keys (values or metadata). Note that commands that don't
|
|
# interact with keys, will not have either `read` or `write`.
|
|
# * write - Writing to keys (values or metadata)
|
|
# * admin - Administrative commands. Normal applications will never need to use
|
|
# these. Includes REPLICAOF, CONFIG, DEBUG, SAVE, MONITOR, ACL, SHUTDOWN, etc.
|
|
# * dangerous - Potentially dangerous (each should be considered with care for
|
|
# various reasons). This includes FLUSHALL, MIGRATE, RESTORE, SORT, KEYS,
|
|
# CLIENT, DEBUG, INFO, CONFIG, SAVE, REPLICAOF, etc.
|
|
# * connection - Commands affecting the connection or other connections.
|
|
# This includes AUTH, SELECT, COMMAND, CLIENT, ECHO, PING, etc.
|
|
# * blocking - Potentially blocking the connection until released by another
|
|
# command.
|
|
# * fast - Fast O(1) commands. May loop on the number of arguments, but not the
|
|
# number of elements in the key.
|
|
# * slow - All commands that are not Fast.
|
|
# * pubsub - PUBLISH / SUBSCRIBE related
|
|
# * transaction - WATCH / MULTI / EXEC related commands.
|
|
# * scripting - Scripting related.
|
|
# * set - Data type: sets related.
|
|
# * sortedset - Data type: zsets related.
|
|
# * list - Data type: lists related.
|
|
# * hash - Data type: hashes related.
|
|
# * string - Data type: strings related.
|
|
# * bitmap - Data type: bitmaps related.
|
|
# * hyperloglog - Data type: hyperloglog related.
|
|
# * geo - Data type: geo related.
|
|
# * stream - Data type: streams related.
|
|
#
|
|
# For more information about ACL configuration please refer to
|
|
# the Redis web site at https://redis.io/topics/acl
|
|
|
|
# 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
|
|
|
|
#################### KERNEL transparent hugepage CONTROL ######################
|
|
|
|
# Usually the kernel Transparent Huge Pages control is set to "madvise" or
|
|
# or "never" by default (/sys/kernel/mm/transparent_hugepage/enabled), in which
|
|
# case this config has no effect. On systems in which it is set to "always",
|
|
# redis will attempt to disable it specifically for the redis process in order
|
|
# to avoid latency problems specifically with fork(2) and CoW.
|
|
# If for some reason you prefer to keep it enabled, you can set this config to
|
|
# "no" and the kernel global to "always".
|
|
disable-thp yes
|
|
|
|
############################## APPEND ONLY MODE ###############################
|
|
|
|
# By default Redis asynchronously dumps the dataset on disk. This mode is
|
|
# good enough in many applications, but an issue with the Redis process or
|
|
# a power outage may result into a few minutes of writes lost (depending on
|
|
# the configured save points).
|
|
#
|
|
# The Append Only File is an alternative persistence mode that provides
|
|
# much better durability. For instance using the default data fsync policy
|
|
# (see later in the config file) Redis can lose just one second of writes in a
|
|
# dramatic event like a server power outage, or a single write if something
|
|
# wrong with the Redis process itself happens, but the operating system is
|
|
# still running correctly.
|
|
#
|
|
# AOF and RDB persistence can be enabled at the same time without problems.
|
|
# If the AOF is enabled on startup Redis will load the AOF, that is the file
|
|
# with the better durability guarantees.
|
|
#
|
|
# Note that changing this value in a config file of an existing database and
|
|
# restarting the server can lead to data loss. A conversion needs to be done
|
|
# by setting it via CONFIG command on a live server first.
|
|
#
|
|
# Please check https://redis.io/topics/persistence for more information.
|
|
|
|
appendonly no
|
|
|
|
# The base name of the append only file.
|
|
#
|
|
# Redis 7 and newer use a set of append-only files to persist the dataset
|
|
# and changes applied to it. There are two basic types of files in use:
|
|
#
|
|
# - Base files, which are a snapshot representing the complete state of the
|
|
# dataset at the time the file was created. Base files can be either in
|
|
# the form of RDB (binary serialized) or AOF (textual commands).
|
|
# - Incremental files, which contain additional commands that were applied
|
|
# to the dataset following the previous file.
|
|
#
|
|
# In addition, manifest files are used to track the files and the order in
|
|
# which they were created and should be applied.
|
|
#
|
|
# Append-only file names are created by Redis following a specific pattern.
|
|
# The file name's prefix is based on the 'appendfilename' configuration
|
|
# parameter, followed by additional information about the sequence and type.
|
|
#
|
|
# For example, if appendfilename is set to appendonly.aof, the following file
|
|
# names could be derived:
|
|
#
|
|
# - appendonly.aof.1.base.rdb as a base file.
|
|
# - appendonly.aof.1.incr.aof, appendonly.aof.2.incr.aof as incremental files.
|
|
# - appendonly.aof.manifest as a manifest file.
|
|
|
|
appendfilename "appendonly.aof"
|
|
|
|
# For convenience, Redis stores all persistent append-only files in a dedicated
|
|
# directory. The name of the directory is determined by the appenddirname
|
|
# configuration parameter.
|
|
|
|
appenddirname "appendonlydir"
|
|
|
|
# The fsync() call tells the Operating System to actually write data on disk
|
|
# instead of waiting for more data in the output buffer. Some OS will really flush
|
|
# data on disk, some other OS will just try to do it ASAP.
|
|
#
|
|
# Redis supports three different modes:
|
|
#
|
|
# no: don't fsync, just let the OS flush the data when it wants. Faster.
|
|
# always: fsync after every write to the append only log. Slow, Safest.
|
|
# everysec: fsync only one time every second. Compromise.
|
|
#
|
|
# The default is "everysec", as that's usually the right compromise between
|
|
# speed and data safety. It's up to you to understand if you can relax this to
|
|
# "no" that will let the operating system flush the output buffer when
|
|
# it wants, for better performances (but if you can live with the idea of
|
|
# some data loss consider the default persistence mode that's snapshotting),
|
|
# or on the contrary, use "always" that's very slow but a bit safer than
|
|
# everysec.
|
|
#
|
|
# More details please check the following article:
|
|
# http://antirez.com/post/redis-persistence-demystified.html
|
|
#
|
|
# If unsure, use "everysec".
|
|
|
|
# appendfsync always
|
|
appendfsync everysec
|
|
# appendfsync no
|
|
|
|
# When the AOF fsync policy is set to always or everysec, and a background
|
|
# saving process (a background save or AOF log background rewriting) is
|
|
# performing a lot of I/O against the disk, in some Linux configurations
|
|
# Redis may block too long on the fsync() call. Note that there is no fix for
|
|
# this currently, as even performing fsync in a different thread will block
|
|
# our synchronous write(2) call.
|
|
#
|
|
# In order to mitigate this problem it's possible to use the following option
|
|
# that will prevent fsync() from being called in the main process while a
|
|
# BGSAVE or BGREWRITEAOF is in progress.
|
|
#
|
|
# This means that while another child is saving, the durability of Redis is
|
|
# the same as "appendfsync no". In practical terms, this means that it is
|
|
# possible to lose up to 30 seconds of log in the worst scenario (with the
|
|
# default Linux settings).
|
|
#
|
|
# If you have latency problems turn this to "yes". Otherwise leave it as
|
|
# "no" that is the safest pick from the point of view of durability.
|
|
|
|
no-appendfsync-on-rewrite no
|
|
|
|
# Automatic rewrite of the append only file.
|
|
# Redis is able to automatically rewrite the log file implicitly calling
|
|
# BGREWRITEAOF when the AOF log size grows by the specified percentage.
|
|
#
|
|
# This is how it works: Redis remembers the size of the AOF file after the
|
|
# latest rewrite (if no rewrite has happened since the restart, the size of
|
|
# the AOF at startup is used).
|
|
#
|
|
# This base size is compared to the current size. If the current size is
|
|
# bigger than the specified percentage, the rewrite is triggered. Also
|
|
# you need to specify a minimal size for the AOF file to be rewritten, this
|
|
# is useful to avoid rewriting the AOF file even if the percentage increase
|
|
# is reached but it is still pretty small.
|
|
#
|
|
# Specify a percentage of zero in order to disable the automatic AOF
|
|
# rewrite feature.
|
|
|
|
auto-aof-rewrite-percentage 100
|
|
auto-aof-rewrite-min-size 64mb
|
|
|
|
# An AOF file may be found to be truncated at the end during the Redis
|
|
# startup process, when the AOF data gets loaded back into memory.
|
|
# This may happen when the system where Redis is running
|
|
# crashes, especially when an ext4 filesystem is mounted without the
|
|
# data=ordered option (however this can't happen when Redis itself
|
|
# crashes or aborts but the operating system still works correctly).
|
|
#
|
|
# Redis can either exit with an error when this happens, or load as much
|
|
# data as possible (the default now) and start if the AOF file is found
|
|
# to be truncated at the end. The following option controls this behavior.
|
|
#
|
|
# If aof-load-truncated is set to yes, a truncated AOF file is loaded and
|
|
# the Redis server starts emitting a log to inform the user of the event.
|
|
# Otherwise if the option is set to no, the server aborts with an error
|
|
# and refuses to start. When the option is set to no, the user requires
|
|
# to fix the AOF file using the "redis-check-aof" utility before to restart
|
|
# the server.
|
|
#
|
|
# Note that if the AOF file will be found to be corrupted in the middle
|
|
# the server will still exit with an error. This option only applies when
|
|
# Redis will try to read more data from the AOF file but not enough bytes
|
|
# will be found.
|
|
aof-load-truncated yes
|
|
|
|
# Redis can create append-only base files in either RDB or AOF formats. Using
|
|
# the RDB format is always faster and more efficient, and disabling it is only
|
|
# supported for backward compatibility purposes.
|
|
aof-use-rdb-preamble yes
|
|
|
|
# Redis supports recording timestamp annotations in the AOF to support restoring
|
|
# the data from a specific point-in-time. However, using this capability changes
|
|
# the AOF format in a way that may not be compatible with existing AOF parsers.
|
|
aof-timestamp-enabled no
|