I have applied the virtual-controller-IP on my master IAP and configuration is persisted on my master IAP which can be viewed in the running configuration of the IAP.
WAP# configure terminal WAP (config) # virtual-controller-ip 200.20.200.237
WAP (config) # end
WAP# commit apply
committing configuration...
configuration committed.
WAP# reload all
Do you really want to reset the system (y/n): y
How to delete or disable this applied configuration using Aruba CLI?
To disable or unset a Virtual Controller IP we need to apply virtual-controller-ip as 0.0.0.0 in the master wap or Virtual controller.
Let's apply virtual-controller-ip as 0.0.0.0 in master WAP.
WAP# configure terminal
We now support CLI commit model, please type "commit apply" for configuration to take effect.
WAP (config) # virtual-controller-ip 0.0.0.0
WAP (config) # end
WAP# commit apply no-save
committing configuration...
Now in the master wap running-config we don't have virtual-controller-ip.
WAP# show running-config
virtual-controller-country US
From Aruba 8.3 MIB, it says when the Virtual controller IP address is not set, it will return 0.0.0.0.
aiVirtualControllerIPAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Virtual Controller IP Address. If this is not set, returns 0.0.0.0"
::= { aiInfoGroup 5 }
Related
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.
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.
log:Creating Server TCP listening socket （myip:port）: bind: Cannot assign requested address
my redis.conf
bind 10.114.234.11
when i cofig like this
bind 127.0.0.1
it works well
You likely do not currently have any interfaces set up for the 10.x.x.x subnet. If you're on any flavor of Linux, ifconfig should be able to tell you which interfaces are currently set up. For example, I'm running Mint 17:
$ ifconfig | grep "inet addr"
inet addr:127.0.0.1 Mask:255.0.0.0
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
So I (like you) would not be able to bind Redis (or most any other service requesting a TCP socket) to 10.x.x.x. If you are really trying to listen for connections on that subnet, you will need to change your network setup (how exactly that would be done depends largely on your operating system).
I also faced same issue while setting up redis for remote access. I was using google cloud platform and we created Google compute engine VM instance where we installed our Redis server. Redis doesn't ship with by default with security configured. You have to perform some steps to secure it. By updating IP address in redis.conf in bind will allow access only from that IP addresses. When we were doing it, we were getting same error.
To solve this issue we haven't added IP addresses in redis.conf file instead in Google cloud firewall rules when we add port open record in network -> IP ranges you can specify IP address which you want allow to access redis. In redis.conf file update from bind 127.0.0.1 to bind 0.0.0.0. So basically we will restrict it from Google cloud firewall rules dashboard.
Below are steps to add IP address restrictions:
Login to your google cloud console
Navigate to VPC Network -> Firewall Rules
Click on CREATE FIREWALL RULE or edit existing one if it's already there
In Source IP ranges add your IP address to allow access only - See below screenshot
Once you create this rule add this source tags under your VM instances network type and you are done.
I have faced the same issue when I changed the default redis.conf to custom Redis conf and after changing the bind as below then it started working, Please be aware that the below conf will open the Redis connection from all sources.
bind 127.0.0.1 -::1 to bind 0.0.0.0 -::1
At /etc/redis/redis.conf
Please change
bind 127.0.0.1 ::1
to
bind 0.0.0.0
then restart
/etc/init.d/redis-server restart
It's work to me
all. I am trying to install openshift with one command
[root#demo ~]# sh <(curl -s https://install.openshift.com/)
Checking for necessary tools...
...looks good.
Downloading oo-install package...
Extracting oo-install to temporary directory...
Starting oo-install...
OpenShift Installer (Build 20140722-1618)
.....
....
....
Deploying workflow 'origin_deploy'.
The OpenShift deployment configuration has the following errors:
* The implied host domain 'com' does not match the specified host domain of 'demo.com' for DNS
Rerun the installer to correct these errors.
I don't know what is the reason it keeps telling me that 'the implied host domain 'com' ...' what need to be changed?
[root#demo ~]# sh <(curl -s https://install.openshift.com/)
Checking for necessary tools...
...looks good.
Downloading oo-install package...
Extracting oo-install to temporary directory...
Starting oo-install...
OpenShift Installer (Build 20140722-1618)
Welcome to OpenShift.
This installer will guide you through a basic system deployment, based
on one of the scenarios below.
Select from the following installation scenarios.
You can also type '?' for Help or 'q' to Quit:
Install OpenShift Origin
Add a Node to an OpenShift Origin deployment
Generate a Puppet Configuration File
Type a selection and press : 1
Your system deployment configuration is incomplete.
The installer will guide you through the necessary configuration
steps.
Note: ActiveMQ and MongoDB will be installed on all Broker instances.
For more flexibility, rerun the installer in advanced mode (-a).
DNS Settings
Installer will deploy DNS
Application Domain: example.com
Register OpenShift hosts with DNS? Yes
Component Domain: demo.com
Global Gear Settings
Account Settings
![enter image description here][2]
Node Districts
Role Assignments
Host Information
The configuration file does not include some of the required settings
for host instance demo.com. Please provide them here.
Hostname (the FQDN that other OpenShift hosts will use to connect to
the host that you are describing): |demo.com|
Hostname / IP address for SSH access to demo.com from the host where
you are running oo-install. You can say 'localhost' if you are running
oo-install from the system that you are describing: |demo.com| 10.1.14.145
Username for SSH access to 10.1.14.145: |root|
Validating root#10.1.14.145... looks good.
Detected multiple network interfaces for this host:
* 192.168.142.128 on interface eth2
* 10.1.14.145 on interface eth3
Do you want to use one of these as the public IP information for this
Node? (y/n/q/?) y
The following network interfaces were found on this host. Choose the
one that it uses for communication on the local subnet:
1. 192.168.142.128 on interface eth2
2. 10.1.14.145 on interface eth3
Type a selection and press : 2
Normally, the BIND DNS server that is installed on this host will be
reachable from other OpenShift components using the host's configured
IP address (10.1.14.145).
If that will work in your deployment, press to accept the
default value. Otherwise, provide an alternate IP address that will
enable other OpenShift components to reach the BIND DNS service on
this host: |10.1.14.145|
This Node host is currently associated with the Default district. Do
you want to change this district assignment? (y/n/q) n
Do you want to modify the account info settings for the various role
services? (y/n/q/?) n
Here are the details of your current deployment.
Note: ActiveMQ and MongoDB will be installed on all Broker instances.
For more flexibility, rerun the installer in advanced mode (-a).
DNS Settings
Installer will deploy DNS
Application Domain: example.com
Register OpenShift hosts with DNS? Yes
Component Domain: demo.com
Choose from the following deployment configuration options:
1. Change the DNS configuration
2. Manage Hosts
3. Services Accounts Settings
4. Global Gear Settings
5. Node Districts
6. Display full Host details
7. Finish editing the deployment configuration
Type a selection and press : 7
Here is the subscription configuration that the installer will use for
this deployment.
Do you want to make any changes to the subscription info in the
configuration file? (y/n/q/?) n
Do you want to set any temporary subscription settings for this
installation only? (y/n/q/?) n
Preflight check: verifying system and resource availability.
Checking demo.com:
* SSH connection succeeded
* Target host is running CentOS
* Located getenforce
* SELinux is running in enforcing mode
* Located yum
* puppet RPM is installed.
* openssh-clients RPM is installed.
* bind RPM is installed.
Deploying workflow 'origin_deploy'.
The OpenShift deployment configuration has the following errors:
* The implied host domain 'com' does not match the specified host domain of 'demo.com' for DNS
Rerun the installer to correct these errors.
The issue is that OpenShift requires hosts to be part of a second-level domain. myhost.openshift.localdomain works, while myhost.localdomain does not.
I entered oshost.localdomain as component domain (configured right after the application domain) and 0.oshost.localdomain for the actual host and now it installs just fine.
I'm trying to setup JMeter in a distributed mode.
I have a server running on an ec2 intance, and I want the master to run on my local computer.
I had to jump through some hopes to get RMI working correctly on the server but was solved with setting the "java.rmi.server.hostname" to the IP of the ec2 instance.
The next (and hopefully last) problem is the server communicating back to the master.
The problem is that because I am doing this from an internal network, the master is sending its local/internal ip address (192.168.1.XXX) when it should be sending back the IP of my external connection (92.XXX.XXX.XXX).
I can see this in the jmeter-server.log:
ERROR - jmeter.samplers.RemoteListenerWrapper: testStarted(host) java.rmi.ConnectException: Connection refused to host: 192.168.1.50; nested exception is:
That host IP is wrong. It should be the 92.XXX.XXX.XX address. I assume this is because in the master logs I see the following:
2012/07/29 20:45:25 INFO - jmeter.JMeter: IP: 192.168.1.50 Name: XXXXXX.local FullName: 192.168.1.50
And this IP is sent to the server during RMI setup.
So I think I have two options:
Tell the master to send the external IP
Tell the server to connect on the external IP of the master.
But I can't see where to set these commands.
Any help would be useful.
For the benefit of future readers, don't take no for an answer. It is possible! Plus you can keep your firewall in place.
In this case, I did everything over port 4000.
How to connect a JMeter client and server for distributed testing with Amazon EC2 instance and local dev machine across different networks.
Setup:
JMeter 2.13 Client: local dev computer (different network)
JMeter 2.13 Server: Amazon EC2 instance
I configured distributed client / server JMeter connectivity as follows:
1. Added a port forwarding rule on my firewall/router:
Port: 4000
Destination: JMeter client private IP address on the LAN.
2. Configured the "Security Group" settings on the EC2 instance:
Type: Allow: Inbound
Port: 4000
Source: JMeter client public IP address (my dev computer/network public IP)
Update: If you already have SSH connectivity, you could use an SSH tunnel for the connection, that will avoid needing to add the firewall rules.
$ ssh -i ~/.ssh/54-179-XXX-XXX.pem ServerAliveInterval=60 -R 4000:localhost:4000 jmeter#54.179.XXX.XXX
3. Configured client $JMETER_HOME/bin/jmeter.properties file RMI section:
note only the non-default values that I changed are included here:
#---------------------------------------------------------------------------
# Remote hosts and RMI configuration
#---------------------------------------------------------------------------
# Remote Hosts - comma delimited
# Add EC2 JMeter server public IP address:Port combo
remote_hosts=127.0.0.1,54.179.XXX.XXX:4000
# RMI port to be used by the server (must start rmiregistry with same port)
server_port=4000
# Parameter that controls the RMI port used by the RemoteSampleListenerImpl (The Controler)
# Default value is 0 which means port is randomly assigned
# You may need to open Firewall port on the Controller machine
client.rmi.localport=4000
# To change the default port (1099) used to access the server:
server.rmi.port=4000
# To use a specific port for the JMeter server engine, define
# the following property before starting the server:
server.rmi.localport=4000
4. Configured remote server $JMETER_HOME/bin/jmeter.properties file RMI section as follows:
#---------------------------------------------------------------------------
# Remote hosts and RMI configuration
#---------------------------------------------------------------------------
# RMI port to be used by the server (must start rmiregistry with same port)
server_port=4000
# Parameter that controls the RMI port used by the RemoteSampleListenerImpl (The Controler)
# Default value is 0 which means port is randomly assigned
# You may need to open Firewall port on the Controller machine
client.rmi.localport=4000
# To use a specific port for the JMeter server engine, define
# the following property before starting the server:
server.rmi.localport=4000
5. Started the JMeter server/slave with:
jmeter-server -Djava.rmi.server.hostname=54.179.XXX.XXX
where 54.179.XXX.XXX is the public IP address of the EC2 server
6. Started the JMeter client/master with:
jmeter -Djava.rmi.server.hostname=121.73.XXX.XXX
where 121.73.XXX.XXX is the public IP address of my client computer.
7. Ran a JMeter test suite.
JMeter GUI log output
Success!
I had a similar problem: the JMeter server tried to connect to the wrong address for sending the results of the test (it tried to connect to localhost).
I solved this by setting the following parameter when starting the JMeter master:
-Djava.rmi.server.hostname=xx.xx.xx.xx
It looks as though this wont work Distributed JMeter Testing explains the requirements for load testing in a distributed environment. Number 2 and 3 are particular to your use case I believe.
The firewalls on the systems are turned off.
All the clients are on the same subnet.
The server is in the same subnet, if 192.x.x.x or 10.x.x.x ip addresses are used.
Make sure JMeter can access the server.
Make sure you use the same version of JMeter on all the systems. Mixing versions may not work correctly.
Might be very late in the game but still. Im running this with jmeter 5.3.
So to get it work by setting up the slaves in aws and the controller on your local machine.
Make sure your slave has the proper localports and hostname. The hostname on the slave should be the ec2 instance public dns.
Make sure AWS has proper security policies.
For the controller (which is your local machine) make sure you run with the parameter '-Djava.rmi.server.hostname='. You can get the ip by googling "my public ip address". Definately not those 192.xxx.xxx.x or 172.xx.xxx.
Then you have to configure your modem to port forward your machine that is used to be your controller. The port can be obtained when from the slave log (the ones that has the FINE: RMI RenewClean....., yeah you have to set the log to verbose). OR set DMZ and put your controller machine. Dangerous, but convinient just for the testing time, don't forget to off it after that
Then it should work.