How to config redis eviction policy runtime? - redis

In the official site, it says:
however you can reconfigure the policy at runtime while the
application is running
How can I achieve if I want to use volatile-lru policy at runtime?

Refer to the CONFIG SET command - for example, to set the eviction policy to 'noeviction' send this command (e.g. via redis-cli):
redis> CONFIG SET maxmemory-policy noeviction

Related

How to configure Kafka server with SASL_SSL and GSSAPI protocols

I am new to Apache Kafka, and here is what I have done so far,
Downloaded kafka_2.12-2.1.0
Make Batch file for Zookeeper to run zookeeper server:
start kafka_2.12-2.1.0.\bin\windows\zookeeper-server-start.bat kafka_2.12-2.1.0.\config\zookeeper.properties
Make Batch File for Apache Kafka server
start kafka_2.12-2.1.0\bin\windows\kafka-server-start.bat kafka_2.12-2.1.0\config\server.properties
Started A Producer using batch file.
start kafka_2.12-2.1.0.\bin\windows\kafka-console-producer.bat --broker-list localhost:9092 --topic 3drocket-player
It is running fine but now I am looking for authentication. As I have to implement a consumer with specific auth settings (requirement by the client). Like security protocol is SASL_SSL and SSL mechanism is GSSAPI.
For this reason, I tried to search and find confluet documentation but the problem is it is too abstract that how to take each and every step.
I am looking for detail configuration steps according to my setup. How to configure my kafka server with SASL SSL and GSSAPI protocol. Initially I found that GSSAPI/Keberos has a separate server then, do i need to install more server? Within Confluent Kafka is there any built-in solution.
Configure a SASL port in server.properties
e.g)
listeners=SASL_SSL://host.name:port
security.inter.broker.protocol=SASL_SSL
sasl.mechanism.inter.broker.protocol=GSSAPI
sasl.enabled.mechanisms=GSSAPI
sasl.kerberos.service.name=kafka
ssl.keystore.location=/path/to/keystore.jks
ssl.keystore.password=keystore_password
ssl.truststore.location=/path/to/truststore.jks
ssl.truststore.password=truststore_password
ssl.enabled.protocols=TLSv1.2,TLSv1.1,TLSv1
https://kafka.apache.org/documentation/#security_configbroker
https://kafka.apache.org/documentation/#security_sasl_config
Client:
When you run the Kafka client, you need to set these properties.
security.protocol=SASL_SSL
ssl.truststore.location=/path/to/truststore.jks
ssl.truststore.password=truststore_password
sasl.mechanism=GSSAPI
sasl.kerberos.service.name=kafka
https://kafka.apache.org/documentation/#security_configclients
https://kafka.apache.org/documentation/#security_sasl_kerberos_clientconfig
Then configure the JAAS configuration
KafkaClient {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab="path/to/kafka_client.keytab"
storeKey=true
useTicketCache=false
principal="kafka-client-1#EXAMPLE.COM";
};
...
SASL/GSSAPI is for organizations using Kerberos (for example, by using Active Directory). You don’t need to install a new server just for Apache Kafka®. Ask your Kerberos administrator for a principal for each Kafka broker in your cluster and for every operating system user that will access Kafka with Kerberos authentication (via clients and tools).
https://docs.confluent.io/current/kafka/authentication_sasl/authentication_sasl_gssapi.html#kafka-sasl-auth-gssapi
....

Exim v4.91: Cant Enable IGNORE_SMTP_LINE_LENGTH_LIMIT = 1 macro to allow long lines

Ever since upgrading to Exim 4.91, legitimate email notifications are being rejected with an error "T=remote_smtp: message is too big (transport limit = 1)".
This appears to be related to a new ACL in Exim as described here to block messages that contain lines longer than 998 octets :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828801
A macro was supposedly added to v4.88~RC6-2, which disables this ACL named IGNORE_SMTP_LINE_LENGTH_LIMIT and to disable the ACL you can configure it to 1.
In my configuration, I have a server that sends email notifications. This server uses another server as a smarthost. I am running centos and have a config at /etc/exim/exim.conf on both servers.
I can't seem to disable this ACL no matter what I do.
I have added IGNORE_SMTP_LINE_LENGTH_LIMIT=1 to the top of both servers exim.conf files and continue to get errors.
Any suggestions on what to do?
I use "one big config-file" (not split-config), and adding
IGNORE_SMTP_LINE_LENGTH_LIMIT=1
to /etc/exim4/exim4.conf.localmacros works.
My configuration is also splitted in multiple files and uses a smarthost. Following these instructions, it works:
Create a new file in acl directory with nano /etc/exim4/conf.d/acl/00_local and put this:
IGNORE_SMTP_LINE_LENGTH_LIMIT=1
Reload configuration with systemctl reload exim4 or restart the service with systemctl restart exim4
Send an email and check the exim logs from /var/log/exim4/mainlog.

Solr Master/Slave SSL Replication Configuration

I need to use SSL in my Master/Slave Solr 6.6.2 environment. This is Solr on Windows as the governance requires all servers to be Windows.
I had created a localhost SSL Cert on the Master (works on the Master because it’s local), but this won’t work for the Slave which has replication based on the IP of the Master server. I then changed it to a self-signed cert that uses the machine name which seems to be a better fit for accessing the site.
However, I can't get replication to work when using SSL/HTTPS. It throws IO Communication errors as it can’t resolve the https connection to a localhost certificate on the Master. The error is as follows:
Master at: https://mastercomputername:8983/solr/core_index is not
available. Index fetch failed by exception:
org.apache.solr.common.SolrException: IOException occured when talking
to server at: https://mastercomputername:8983/solr/core_index
Is there a setting in Solr I need to enable to allow replication to occur over HTTPS? I already installed the machine named cert from the Master server on the Slave server and set the Solr.in to accept SSL as follows:
REM Uncomment to set SSL-related system properties
REM Be sure to update the paths to the correct keystore for your environment
set SOLR_SSL_KEY_STORE=D:\Solr\solr-6.6.2\server\etc\solr-ssl.keystore.pfx
set SOLR_SSL_KEY_STORE_PASSWORD=secret
REM set SOLR_SSL_KEY_STORE_TYPE=JKS
set SOLR_SSL_TRUST_STORE=D:\Solr\solr-6.6.2\server\etc\solr-ssl.keystore.pfx
set SOLR_SSL_TRUST_STORE_PASSWORD=secret
REM set SOLR_SSL_TRUST_STORE_TYPE=JKS
REM set SOLR_SSL_NEED_CLIENT_AUTH=false
REM set SOLR_SSL_WANT_CLIENT_AUTH=false
I am thinking that Solr is not listening on 443... or that because it is a self-signed certificate, Java is rejecting it.

How can you disable protected mode in Redis 3.2.6 Sentinel?

I have attempted everything recommended by the following error message:
(error) DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients. In this mode connections are only accepted from the loopback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions: 1) Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent. 2) Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server. 3) If you started the server manually just for testing, restart it with the '--protected-mode no' option. 4) Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.
My /etc/redis/sentinel.conf:
daemonize yes
sentinel myid XXX
sentinel monitor master XXX 6379 2
sentinel down-after-milliseconds master 60000
sentinel config-epoch master 0
protected-mode no
bind 0.0.0.0
port 26379
EDIT: My /etc/redis/redis.conf:
port 6379
bind 0.0.0.0
protected-mode no
I've also tried adding sentinel auth-pass master XXX.
My entire backend is on private subnets. I'm VPN'd into my datacenter behind the firewall, coming from the same private network, and I can still only connect locally without getting that frustrating error message.
Server Environment: Debian 8, Redis 3.2.6
Client Environment: Ubuntu 16.10, redis-cli 3.2.1
Redis instances: 3
Sentinel instances: 3
I've done not just one, but 3/4 of the things suggested (didn't set the command-line flags). Does anyone have any guidance or ideas? I'm clearly missing something that I've been unable to figure out from the error message, documentation, Stackoverflow, Google, and trial & error. I figured I'd post a question here first, before diving into the source code.
Any help is appreciated. Thanks!
... and, yes, I've restarted the daemons after configuration changes. :)
https://www.reddit.com/r/redis/comments/3zv85m/new_security_feature_redis_protected_mode/
As you know we got several problems from unprotected Redis instances exposed to the internet. I covered the reason why a restrictive binding to 127.0.0.1 by default may be an usability concern and, even worse, may not fix the problem (hey just comment the "bind" statement and restart!) in my blog post.
The same blog post introduced an attack that was heavily used by script kiddies to break into Redis instances (serious security researchers where already able to do this, I guess).
So I finally decided to do something before Redis 3.2 official release: Protected mode is the result and will be merged into 3.2 RC2.
The feature is already available in the unstable branch, introduced by this commit. This is how it works.
If and only if:
Protected mode is enabled (this is the default both in the configuration file and in the configless default).
AND IF No AUTH password is configured.
AND IF No "bind" directive is used in order to restrict Redis to certain interfaces.
Then Redis only accepts connections from the loopback IPv4 and IPv6 addresses. External connections are accepted just for the time to send the client an error that makes the user aware of what is happening:
> PING
(error) DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients.
In this mode connections are only accepted from the lookback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions:
Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent.
Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server.
If you started the server manually just for testing, restart it with the --protected-mode no option.
Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.
This should protect errors in a reasonable way while providing users with a clue instead of a connection refused. Please share your feedbacks so that we can make changes to this feature if needed, before it will get merged into Redis 3.2 RC2. Thanks.

How to configure Redis 3.4 and above in master/slave config to resolve error Sentinel running on protected mode?

I am working with Redis 3.2 and while connecting to the sentinel from a differnt machine I get the following error:
Trying X.X.X.X...
Connected to X.X.X.X.
Escape character is '^]'.
-DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients. In this mode connections are only accepted from the loopback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions: 1) Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent. 2) Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server. 3) If you started the server manually just for testing, restart it with the '--protected-mode no' option. 4) Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.
Connection closed by foreign host.
Can somene help me resolve this?
From redis 3.2, Sentinel by default, is not reachable from interfaces other than localhost.
Either use the 'bind' directive to bind to a list of network interfaces, or disable protected mode with "protected-mode no" by adding it to this configuration file.
For example you may use one of the following:
bind 127.0.0.1 192.168.1.1
protected-mode no
For testing, you can try
redis-server --protected-mode no
This will set Redis protected mode to no.
As from documentation suggested steps.
1) Just disable protected mode sending the command 'CONFIG SET
protected-mode no' from the loopback interface by connecting to Redis
from the same host the server is running, however MAKE SURE Redis is
not publicly accessible from internet if you do so. Use CONFIG REWRITE
to make this change permanent.
2) Alternatively you can just disable the protected mode by editing
the Redis configuration file, and setting the protected mode option to
'no', and then restarting the server.
3) If you started the server manually just for testing, restart it
with the '--protected-mode no' option.
4) Setup a bind address or an authentication password. NOTE: You only
need to do one of the above things in order for the server to start
accepting connections from the outside.