The page of migration to "tomcat 8" says (http://tomcat.apache.org/migration-8.html):
"When starting Tomcat with the jpda option to enable remote debugging, Tomcat 8 listens on localhost:8000 by default. Earlier versions listened on *:8000"
1.what is the actual different between those configuration?
Thanks,
Eyal
I have filed that issue to change that to Tomcat 8. For a very good reason: If you provide *:8080, everyone who is on your network is able to hook into your VM and debug and maybe disclose sensitive data, moreover periodical Nessus scan in my company and others report that as a vulnerability. All you need to do is set the environment variable JPDA_ADDRESS to IP:PORT, ideally in your setenv.sh.
Related
I am pretty new to Java and Tomcat but we have no one else that has any clue on either one so I get to try and remedy the issue.
We are recently upgrading from Tomcat 8 to Tomcat 9. I am trying to enable authentication due to a Qualys open vulnerability of JMX RMI accessible with common credentials. I have the following settings defined in the Java Options:
-Dcom.sun.management.jmxremote.port=8080
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.password.file=C:\Program Files\Java\jre1.8.0_291\lib\management\jmxremote.password
-Dcom.sun.management.jmxremote.access.file=C:\Program Files\Java\jre1.8.0_291\lib\management\jmxremote.access
I currently have both Tomcat 8 and Tomcat 9 installed. They are both using the same Java Options. However, when I start the Tomcat 9 service, I get a error 1067 about the process terminating unexpectedly.
Tomcat 8 with the same setting starts and runs fine. If I set the option to authenticate to false, Tomcat 9 has no problems starting and running. Is there any additional Java Options that I need to add with Tomcat 9 that I did not need with Tomcat 8?
This is only needed to close the Qualys vulnerability. The server does not actually need to connect using JMX remotely.
I'm connecting to the WebSphere instance from the stand-alone Java app which is quite trivial:
InitialContext initCtx = new InitialContext();
That code was working perfectly in WebSphere 7, but after updating to WebSphere 8.5 I got the following exception:
Caused by: org.omg.CORBA.TRANSIENT: initial and forwarded IOR inaccessible vmcid: IBM minor code: E07 completed: No
at com.ibm.rmi.corba.ClientDelegate.createRequest(ClientDelegate.java:1276)
at com.ibm.CORBA.iiop.ClientDelegate.createRequest(ClientDelegate.java:1457)
at com.ibm.rmi.corba.ClientDelegate.createRequest(ClientDelegate.java:1164)
at com.ibm.CORBA.iiop.ClientDelegate.createRequest(ClientDelegate.java:1423)
at com.ibm.rmi.corba.ClientDelegate.request(ClientDelegate.java:1886)
at com.ibm.CORBA.iiop.ClientDelegate.request(ClientDelegate.java:1379)
at org.omg.CORBA.portable.ObjectImpl._request(ObjectImpl.java:458)
at com.ibm.WsnBootstrap._WsnNameServiceStub.getProperties(_WsnNameServiceStub.java:38)
at com.ibm.ws.naming.util.WsnInitCtxFactory.mergeWsnNSProperties(WsnInitCtxFactory.java:1441)
... 43 more
After research, I've fout out that IBM support page, which said to go to CSIv2 inbound and outbound settings (by me, Admin Console->Security->GlobalSecurity->RMI/IIOP security) and set the transport to SSL-Supported.
However, it didn't change anything. I've tried to change the 'Cleint certificate authentication' to Never, and Transport to TCP/IP for both CSIv2 inbound and outbound, but still without success. The error persisted until I've turned off 'Enable administrative security', which is not an option, because I need to enable 'Application Security' (the application logic depends of that).
How can I make my code working again? Everything was OK on WebSphere 7.
My research on this issue may prove useful to others;
WebSphere 8 changed the default setting of RMI/IIOP SSL security from
'supported' to 'required'. If you want a secure connection you'll need
to get the certs from the server and set Java system properties to files that specify the location of the certs;
com.ibm.CORBA.ConfigURL=file:/opt/IBM/JazzSM/profile/properties/sas.client.props
com.ibm.SSL.ConfigURL=file:/opt/IBM/JazzSM/profile/properties/ssl.client.props
If this doesn't work, you'll need to start debugging by setting the following System properties;
com.ibm.CORBA.Debug=true
com.ibm.CORBA.CommTrace=true
com.ibm.CORBA.Debug.Output=/tmp/corba.log
By studying this log and orb trace logs in the working directory, I found that the client failed to establish an ephemeral TCP connection to the server at "port=0". No mention of SSL in the logs! I wrote a small app to test my code running as a java console app and found that the SSL connection was successful and it worked fine. By diff'ing the logs, I found that only in the good case, the JVM was finding a local file 'orb.properties'. I then found that in my problem case, my test app was using a different JVM and my real app was using a JVM that had no 'orb.properties'. I could resolve the problem in a number of ways .. e.g. by including an orb.properties in my application and injecting the contents as System properties.
In my case switching CSIV inbound to SSL-Supported from SSL-required and restarting the server helped.
The error description
org.omg.CORBA.TRANSIENT: initial and forwarded IOR inaccessible vmcid: IBM minor code: E07
is very vague and happens under many, not directly connected circumstances.
In my case it had nothing to do with RMI/IIOP security settings, but it was a classpath problem. I was still using old version of com.ibm.ws.webservices.thinclient.
Switching to thinclient 8.5.0, as well as setting the launch JRE to standard (Oracle) JVM has fixed the problem.
When I am using WAS Liberty profile V8.5 beta, I can not find anywhere to change default service port 9080 in RAD, I tried to add httpendpoint section in server.xml, liberty server reports configuration update successful, but got failure when running web application.
Anybody knows how to solve this? Thanks!
There was a bug in the beta which prevented some port changes from being preserved when the server was restarted. There is a forum thread discussing the issue with the cached port value, and the answer is to start the server with the --clean option (from the command line), there is an equivalent checkbox available when you start the server via the tools.
[1] https://www.ibm.com/developerworks/forums/thread.jspa?messageID=14770100
I would start there.
I have a Tomcat installation where I suspect the thread pool may be decreasing over time due to threads not being properly released. I get an error in catalina.out when maxthreads is reached, but I would like to log the number of threads in use to a file every five minutes so I can verify this hypothesis. Would anyone please be able to advise how this can be be done?
Also in this installation there is no Tomcat manager, it appears whoever did the original installation deleted the manager webapp for some reason. I'm not sure if manager would be able to do the above or if I can reinstall it without damaging the existing installation? All I really want to do is keep track of the thread pool.
Also, I noticed that maxthreads for Tomcat is 200, but the max number of concurrent connections for Apache is lower (Apache is using mod_proxy and mod_proxy_ajp (AJP 1.3) to feed Tomcat). That seems wrong too, what is the correct relationship between these numbers?
Any help much appreciated :D
Update: Just a quick update to say the direct JMX access worked. However I also had to set Dcom.sun.management.jmxremote.host. I set it to localhost and it worked, however without it no dice. If anyone else has a similar problem trying to enable JMX I recommend you set this value also, even if you are connecting from the local machine. Seems it is required with some versions of Tomcat.
Just a quick update to say the direct JMX access worked. However I also had to set Dcom.sun.management.jmxremote.host. I set it to localhost and it worked, however without it no dice. If anyone else has a similar problem trying to enable JMX I recommend you set this value also, even if you are connecting from the local machine. Seems it is required with some versions of Tomcat.
Direct JMX access
Try adding this to catalina.sh/bat:
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=5005
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
UPDATE: Alex P suggest that the following settings might also be required in some situations:
-Dcom.sun.management.jmxremote.host=localhost
This enables remote anonymous JMX connections on port 5005. You may also consider JVisualVM which is much more please and allows to browse JMX via plugin.
What you are looking for is Catalina -> ThreadPool -> http-bio-8080 -> various interesting metrics.
JMX proxy servlet
Easier method might be to use Tomcat's JMX proxy servlet under: http://localhost:8080/manager/jmxproxy. For instance try this query:
$ curl --user tomcat:tomcat http://localhost:8080/manager/jmxproxy?qry=Catalina:name=%22http-bio-8080%22,type=ThreadPool
A little bit of grepping and scripting and you can easily and remotely monitor your application. Note that tomcat:tomcat is the username/password of user having manager-jmx role in conf/tomcat-users.xml.
You can deploy jolokia.war and then retrieve mbeans values in JSON (without the manager):
http://localhost:8080/jolokia/read/Catalina:name=*,type=ThreadPool?ignoreErrors=true
If you want only some values (currentThreadsBusy, maxThreads, currentThreadCount, connectionCount):
http://localhost:8080/jolokia/read/Catalina:name=*,type=ThreadPool/currentThreadsBusy,maxThreads,currentThreadCount,connectionCount?ignoreErrors=true
{
request: {
mbean: "Catalina:name="http-nio-8080",type=ThreadPool",
attribute: [
"currentThreadsBusy",
"maxThreads",
"currentThreadCount",
"connectionCount"
],
type: "read"
},
value: {
currentThreadsBusy: 1,
connectionCount: 4,
currentThreadCount: 10,
maxThreads: 200
},
timestamp: 1490396960,
status: 200
}
Note: This example works on Tomcat7 +.
For a more enterprise solution. I have been using New Relic in our production environment.
This provides a graph of the changes to the threadpool over time.
There are cheaper tools out meanwhile: I am using this jar here: https://docs.cyclopsgroup.org/jmxterm
You can automate it via shell/batch scripts. I regexed the output and let prometheus poll it for displaying it in grafana.
I've deployed some Managed Beans on WebSphere 6.1 and I've managed to invoke them through a standalone client, but when I try to use the application "jconsole" distributed with the standard JDK can can't make it works.
Has anyone achieved to connect the jconsole with WAS 6.1?
IBM WebSphere 6.1 it's supossed to support JSR 160 JavaTM Management Extensions (JMX) Remote API. Furthermore, it uses the MX4J implementation (http://mx4j.sourceforge.net). But I can't make it works with neither "jconsole" nor "MC4J".
I have the Classpath and the JAVA_HOME correctly setted, so the issue it's not there.
WebSphere's support for JMX is crap. Particularly, if you need to connect to any secured JMX beans. Here's an interesting tidbit, their own implementation of jConsole will not connect to their own JVM. I have had a PMR open with IBM for over a year to fix this issue, and have gotten nothing but the runaround. They clearly don't want to fix this issue.
The only way I have been able to invoke remote secured JMX beans hosted on WebSphere has been to implement a client using the "WebSphere application client". This is basically a stripped down app server used for stuff like this.
Open a PMR with IBM. Perhaps if more people report this issue, they will actually fix it.
Update: You can run your application as a WebSphere Application Client in RAD. Open the run menu, then choose "Run...". In the dialog that opens, towards the bottom on the left hand side, you will see "WebSphere v6.1 Application Client". I'm not sure how to start and Application Client outside of RAD.
IT WORKS !
http://issues.apache.org/jira/browse/GERONIMO-4534;jsessionid=FB20DD5973F01DD2D470FB9A1B45D209?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
1) Change the config.xml and start the server.
-see here how to change config.xml: http://publib.boulder.ibm.com/wasce/V2.1.0/en/working-with-jconsole.html
2) start the jconsole with : jconsole -J-Djavax.net.ssl.keyStore=%GERONIMO_HOME%\var\security\keystores\geronimo-default -J-Djavax.net.ssl.keyStorePassword=secret -J-Djavax.net.ssl.trustStore=%GERONIMO_HOME%\var\security\keystores\geronimo-default -J-Djavax.net.ssl.trustStorePassword=secret -J-Djava.class.path=%JAVA_HOME%\lib\jconsole.jar;%JAVA_HOME%\lib\tools.jar;%GERONIMO_HOME%\repository\org\apache\geronimo\framework\geronimo-kernel\2.1.4\geronimo-kernel-2.1.4.jar
[or your version of geronimo-kernel jar]
3) in the jconsole interface->advanced, input:
JMX URL: service:jmx:rmi:///jndi/rmi://localhost:1099/JMXSecureConnector
user name: system
password: manager
4) click the connect button.
If you want the WebSphere MBeans this one works for me:
The key is to configure the classpath and the security properly.
in one line:
jconsole -J-Dwas.install.root=C:/was61 -J-Djava.ext.dirs=C:/was61/plugins;C:/was61/plugins/com.ibm.ws.security.crypto_6.1.0;C:/was61/lib;C:/was61/java/jre/lib/ext -J-Dcom.ibm.SSL.ConfigURL="file:../../properties/ssl.client.props" -J-Dcom.ibm.CORBA.ConfigURL="file:../../properties/sas.client.props" service:jmx:iiop://host:port/jndi/JMXConnector
where port = bootstrap port ex: (2809)
Be careful when setting the sas and the ssl props.
Robert
I have successfully connected to ActiveMQ and ServiceMix using the JConsole. Does WAS 6.1 use Java Management Extension (JMX) technology? JMX is required for JConsole.
If your path is set correctly it should work fine. On windows you go to System Properties -> Advanced Tab -> Environment Variables. Have your JAVA_HOME System variable set to the path of your JDK or JRE and your Path variable with %JAVA_HOME%/bin added somewhere in there. Then all you need to do is go to Start->Run->JConsole. Select the correct Process Name and your done.
Where are you having problems at? I hope this helps.
Edit:
Here is the Java Doc's on JConsole.
Hmm... I know that WebSphere is kind of hard to configure. Thats part of the reason we used ServiceMix for our ESB. Maybe its not enabled by default in WebSphere and you would have to turn it on in the config somewhere.
Websphere 6.1 does not support the JConsole for some reason even though it fully implements the JMS specs. Seems to be a week area at the moment. Your best bet is to look at the Admin client to implement you own console.
You all seem to be incorrect. I am running Websphere 6.1.041 , using JDK 1.5 , and I just started up Jconsole and used the "simple connect" tab to connect to localhost with port=0 and without a username and password and it works fine.