and after cluster started. each node show's it's ip:port as 127.0.0.1:3000x
and the client is on another machine. certainly can't reach 127.0.0.1:3000x
is there any configuration to ask the redis nodes use a subnet ip instead of 127.0.0.1?
I didn't found any host configuration in config.
*** FATAL CONFIG FILE ERROR ***
Reading the configuration file, at line 1
>>> 'host 10.1.130.193'
I found bind directive. and used it. each node tells me that IP address for this node updated to 10.1.130.193.
problem solved.
just use bind instead of host.
Related
I've setup a weblogic cluster with 2 managed servers.In order to configure node manager on both nodes i've followed the related article :
http://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/wls/12c/12_2_1/01-12-001-ConfiguringandUsingNodeManager/Configuring_and_Using_NM.html
with the following configuration :
Machine-0 :
DomainsFile=/u01/app/oracle/config/domains/base_domain/Machine-
0/nodemanager.domains
LogLimit=0
PropertiesVersion=12.1.3
AuthenticationEnabled=true
NodeManagerHome=/u01/app/oracle/config/domains/base_domain/Machine-0
JavaHome=/opt/jdk1.8.0_131
LogLevel=INFO
DomainsFileEnabled=true
StartScriptName=startWebLogic.sh
ListenAddress=localhost
NativeVersionEnabled=true
ListenPort=5558
LogToStderr=true
SecureListener=false
LogCount=1
StopScriptEnabled=false
QuitEnabled=false
LogAppend=true
StateCheckInterval=500
CrashRecoveryEnabled=false
StartScriptEnabled=true
LogFile=/u01/app/oracle/config/domains/base_domain/Machine-
0/nodemanager.log
LogFormatter=weblogic.nodemanager.server.LogFormatter
ListenBacklog=50
Machine-1 (the second managed server) has the same configuration with the exceptions of ports (5557) and name.
Although node manager is successfully started on both machines (startNodeManager.sh on machine-0 and machine-1) from admin console on Machine-0 the following error occurs and node manager doesnt start :
weblogic.nodemanager.NMConnectException
nodemanager.log of Machine-0 has no indications of errors or any helpful stuff.
Any help would be appreciated.
thanks in advance
These are the things that I usually check when I am setting up a new WebLogic domain:
It is possible that the Listen Address of Machine-1 is not correct. Check the Listen Address of the machine from the WebLogic Domain Configuration. It should match the host's machine name. Using localhost might not work because the Admin Server is trying to connect to the Machine-1, which can be on the other server.
Make sure to check if the port is reachable from the Admin Server's machine.
Check that the Node Manager configuration uses Plain instead of SSL connection, as stated in your nodemanager.properties file. Under Environments > Machines, click the machine and go to Configuration Tab, Node Manager. Check if the Type is Plain and not SSL. Changing this will require a restart of the Admin Server.
Please verify the items below before you start nodemanager.
Check if the nodemanager.domains has your domain name listed.
Try to see if the ports are listening using the commands below.
netstat -an|grep 5557
netstat -an|grep 5558
Also, check if the nodemanager is reachable in weblogic console.
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
We are using NSS as SSL engine in Apache server. Recently we applied latest SUSE Linux Enterprise server patches on Apache server which is hosting two IP based virtual hosts. After upgrade the first virtual host is working fine but the second one is not working.
Error log shows "Hostname vhost1.xxyyzz.com provided via SNI and hostname vhost2.xxyyzz.com provided via HTTP are different" when accessing vhost2.xxyyzz.com.
If we switch back to use mod_ssl the issue was gone. Obviously the issue is related to the following patches. Any help would be appreciated.
mozilla-nss 3.16.4-0.8.1
mozilla-nss-tools 3.16.4-0.8.1
apache2-mod_nss 1.0.8-0.4.9.1
Check your /etc/hosts file to see if you might be assigning the domain name to a local internal IP address or interface.
This caused the same error message for me and many 400 errors.
After changing /etc/hosts don't forget to restart the name service cache daemon ( service nscd restart ).
SNI isn't technically fully supported in that version of mod_nss but it has since been added: https://www.suse.com/support/update/announcement/2015/suse-ru-20150591-1.html
Saw the same error and saw it go away after applying the referenced patch.
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.
I am a newbie with Apache. I am learning .. after the installation when I tried to start the service I got the following errors.
The Apache service named reported the following error:
Unable to open logs .
The Apache service named reported the following error:
no listening sockets available, shutting down .
The Apache service named reported the following error:
(OS 10048)Only one usage of each socket address (protocol/network address/port) is normally permitted. : make_sock: could not bind to address 0.0.0.0:80 .
The Apache service named reported the following error:
httpd.exe: Could not reliably determine the server's fully qualified domain name, using 192.168.1.6 for ServerName .
The following error usually means that some other program is listening on the HTTP port (80).
(OS 10048)Only one usage of each
socket address (protocol/network
address/port) is normally permitted. :
make_sock: could not bind to address
0.0.0.0:80 .
In my experience, IM (chat) clients like to connect to port 80.
From a command prompt, (cmd.exe) run the command:
netstat -an
See if there is a listener on port 80 (Look for a line that says:
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING
=== ====
the important thing being TCP and 80. If you find something, you'll need to track it down using something like TcpView
If Skype is your problem and it seems it usually is, alter Skype's port usage.
Click on Tools in Skype,
click on Options,
click Advanced,
click Connections.
In Connection is the option to use another port, I use a high numbered port such as 65432, then un-click the alternative use of port 80 and 443.
Close and restart Skype.
modifying C:\Program Files\Apache Software Foundation\Apache2.2\conf\httpd sloved the problem.
If you had installation problems, note that you might experience some errors such “ no services installed ”
if Apache is trying to share port 80 with another web server or application, such as a locally installed
firewall application. To fix this, you can tell Apache to use a different port. Open your httpd.conf file
in the conf subdirectory ( C:\Program Files\Apache Software Foundation\Apache2.2\conf by
default) and locate the following lines:
# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, instead of the default. See also the < VirtualHost >
# directive.
#
# Change this to Listen on specific IP addresses as shown below to
# prevent Apache from glomming onto all bound IP addresses (0.0.0.0)
#
#Listen 12.34.56.78:80
Listen 80
Change the last line of this block to read:
Listen 8080
skype uses port 80, try logout and shut down the program...
now run apache
if you are using windows os and believe that skype is not the suspect, then you might want to check the task manager and check the "Show processes from all users" and make sure that there is NO entry for httpd.exe. Otherwise, end its process. That solves my problem.
Changing in the config file every occurrence of the path to apache (eg: "C:/Users/xxxx/Desktop/Apache Software Foundation/") to the new location (in case you shifted directory of apache installation by copy paste) solved my problem. Hope it helps you too..
Please note that, not only http port 80, may your ssl port 443 is being used by any other service or software.
I have installed vmware workstation on my PC, so a process which was initiated by Vmware Workstation was using ssl port 443.
In my case, it was vmware-hostd.exe which was utilizing ssl port 443.
Try shutting down vmware-hostd.exe or simply change your ssl-httpd.conf and modify Listen from 443 to 8080 or something else.
While choosing the port number please be sure that you don't enter any port which can be used by any other software on your PC.
just provide the listen address and port in httpd.conf file. that will not show IP related error as
Listen IP_ADDRESS:PORT
If you change port ( not port 80) then port conflict will not occur and server comes up.
Below blog may help you :-
http://apache2-4-9-webserver-installation.blogspot.com/2014/06/how-to-install-apache-http-server.html
Port 80 conflict. There are a number of well-known Windows programs which use
port 80:
IIS
The most likely culprit is Microsoft Internet Information Server. Stop the
service with the command from the command line on Windows 7/Vista:
net stop was /y
If needed start the services again with the command from the command line on
windows /Vista:
net start was /y