Weblogic NodeManager Start Failure - weblogic

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.

Related

How to set up SSL on WildFly 9 Domain Mode?

I currently have a WildFly 9 cluster up and running with access to my application over port 8080, I would like to set up SSL and have access only on port 8443, but I cannot seem to find any documentation for where the security realm and https listener are placed in Domain mode.
I have the keystore and certificate all set up and was able to get https working in a demo using standalone mode, but I need to be able to do it in domain mode.
Can anyone help me out and share how they've accomplished this?
Solved it! It turns out for some reason JBoss was not registering my Security Realm and HTTPS listener. To do this you need to use bin/jbosscli and the commands:
RUN THE "CONNECT" COMMAND FIRST
/host=master/core-service=management/security-realm=SSLRealm/:add()
---where SSLRealm is the name of the realm
/host=master/core-service=management/security-realm=SSLRealm/server-identity=ssl/:add(keystore-path=Keystore.jks, keystore-relative-to=jboss.domain.config.dir, keystore-password=password)
---this assumes the keystore lives in the domain/configuration directory
Restart the server.
I then ran into issues figuring out the command to register the HTTPS listener, but I found the WildFly web console at serverURL:9990 has a way to do it too:
Once logged in to the webconsole
Configuration->Profiles->for each profile which is used->Undertow->HTTP->View
From there
HTTP Server->default-server->view
Finally
HTTPS Listener->ADD enter a name like: default-https, Security Realm: the name chosen for the security realm (for this example SSLRealm), Socket Binding: https and click save
Restart again
You should now have access at your serversURL:8443
To set it up on slave servers you should only need to copy the keystore to each slave servers domain/configuration and then add the security realm replacing /host=master/ with /host=slave/ in the command. And then restart the server.
Double check the Domain.xml file on the slave has the https listener you created originally in the webconsole (it should automatically be put into all of the clusters domain.xml files)

How to setup puppet master as a node

Currently I have a master and agent working on separate Centos 6.5 VMs. I would like to be able to configure my own master as I will be tearing down and making a new master every time.
How can I get puppet agent --test --noop to work on my master machine as well?
Currently I receive an error:
Error: Could not request certificate: 502 "Proxy Error ( The specified Secure Sockets Layer (SSL) port is not allowed. ISA Server is not configured to allow SSL requests from this port. Most Web browsers use port 443 for SSL requests. )"
SSL requests seem to be setup for port 443. Any thoughts?
Thank you very much!
Jason
Credit to Felix Frank, mr_tron
Issue seemed to be solved by removing http_proxy declaration in .bashrc file and anywhere else
Puppet Master now able to act as an agent
Thank you,
Jason

How to run glassfish 4 on port 80 instead of 8080? root access is not an issue

Did some google on it and the solution was to redirect using iptables or mod in apache? Since my application uses websockets the above solution breaks my websocket connectivity and I again have to connect to my websockets using port 8080. Is there any way that I can run the glassfish itself on port 80 so that my websockets also run on port 80 making easier for users behind corporate firewall to access the app since corparates may block 8080.
I have root access as well.
To run GlassFish on port 80 you need to :
Connect to the administration interface (by default on port :4848)
In the left menu go to Configurations
Then select the appropriate configuration you need to change eg server-config
Then go to Network Config
Then go to Network Listeners
Select the appropriate listener, probably http-listener-1
Change the Port value to 80
Save and reboot your GlassFish server/instance/cluster according to your needs
Using the command line utility
asadmin set configs.config.server-config.network-config.network-listeners.network-listener.http-listener-1.port=80
you may need to replace server-config and/or http-listener-1
Go to glassfish4\glassfish\domains\domain1\config folder and here open domain.xml file
and find tag
<network-listeners>
<network-listener port="9999" protocol="http-listener-1" transport="tcp" name="http-listener-1" thread-pool="http-thread-pool"></network-listener>
</network-listeners>
in port attribute of <network-listeners> you can specify your port address whichever you want.
Here's another approach.
You can go to the admin console under port 4848 (I am using Glassfish 4.1.2) and navigate to "Configuration" > "server-config" > "HTTP Service" > "Http Listeners" > "http-listener-1" in the left hand navigation.
Click on the "http-listener-1" link in the main content window.
Change the port to desired number and save.
Restart Glassfish and run your application.
in some cases you have to change port before glassfish is started (in my case port 8080 is already in use by another instance) so answer 4 worked for me.
Following are simple steps to change the port number of Glassfish server (GlassFish runs by default on port number 8080):
Go to the folder where Glassfish is installed.
Locate config folder which is as follows (Windows):
C:\Program Files\glassfish-3.0.1\glassfish\domains\domain1\config
Open domain.xml using any text editor.
Look for 8080 and change it to some other port number that doesn’t conflict with other port numbers (e.g. 8081).
Save domain.xml.
Additional step if necessary:
Now remove GlassFish from IDE and add it again so that IDE understands the new port number.
Restart GlassFish, if it was already running.
Soruce Link

JMeter with remote servers

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.

How to disable and enable admin console (admin-listener, port 4848) from the command line

I would like to control when and where the admin service is accessible
How do I do one of the following (if possible)
Enable the admin console only from localhost (I know about disable-secure-admin, but still I don't want anyone to see the console login page when they add 4848 in the end)
I will use SSH tunnle to connect
Or, be able to use a certificate, so only certified clients will be able to even see the console
Or, be able on demand to start / stop the admin service when needed, not opening it to the outside world (e.g. start stop __asadmin virtual server)
Is any of the above possible?
Ok, I found it by guess-work
Solution to scenario #1
Make sure you have SSH tunnel on port 4848 first
Go to Configuration -> server-config -> Network Config -> Network Listeners -> admin-listener
Under the General tab, in the Address: field replace 0.0.0.0 to 127.0.0.1
Restart the server
Solution to scenario #3
I didn't find any command line way to enable / disable virtual servers, network listeners or protocols, but editing domain.xml shows that it's all there, just comment out and restart.
Use asadmin to update the The HTTP Network Listener named admin-listener.
asadmin enable-secure-admin-principal
"Instructs GlassFish Server, when secure admin is enabled, to accept admin requests from clients identified by the specified SSL certificate".
asadmin enable-secure-admin "enables secure admin (if it is not already enabled), optionally changing the alias used for DAS-to-instance admin messages or the alias used for instance-to-DAS admin messages". Also a good blog on the subject. This doesn't turn admin on/off, but enables/disables for remote access to the admin console without the complications of (1).