James,
On 10/20/25 11:54 AM, James H. H. Lampert wrote:
On 10/20/25 6:33 AM, Christopher Schultz wrote:
So... which file were you changing? ;)
I thought I'd made that clear from the beginning (note that for clarity
here, I'm calling the manager context "manager" here; on the "guinea
pig" box, it's been renamed to something different):
1. Use JMXTerm to manually call "stop" on
Catalina:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//
localhost/manager
2. manually (from a separate TN5250 session at native level) change the
manager app's META-INF/context.xml to change the
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
in various ways, either commenting it out, uncommenting it, or changing
the "allow" attribute to add or remove IP addresses
So there is the file in
CATALINA_HOME/webapps/yourapp/META-INF/context.xml but that file gets
copied into CATALINA_HOME/conf/Catalina/localhost/yourapp.xml when your
application is deployed, if it doesn't already exist. If the application
is re-deployed (without being undeployed), that file IS NOT UPDATED. And
this file is preferred by Tomcat, so it won't load the file you have in
bundled with your application.
This is why I keep asking about which file you have modified. Because it
might be the wrong file.
3. Back in the JMXTerm session, manually call "start" on that same bean.
If restarting the context reloaded the META-INF/context.xml, all the
variations on that procedure would have worked just fine. But none of
them had the slightest effect: it just continued to use the manager's
META-INF/context.xml as it existed at the time of Tomcat launch.
But what intrigued me was when you said:
If you use jmxterm to change the RemoteAddrValve's IP address range,
you will change the configuration in memory but not on the disk.
That would actually be the ideal situation: it would reduce a 3-step
manual procedure (both for turning the manager on, and for turning it
off) down to one step, and if I forget to turn it off, it would turn off
anyway at the next scheduled Tomcat restart.
+1
I actually *don't* want to be able to call JMX through anything other
than a terminal session, because that would open a different security
hole. By way of analogy, when I bought my Nissan Leaf, one of the
reasons why I chose a United Chargers of Canada "Grizzl-E" for my home
charging station was that the maximum charging rate is set with a DIP-
switch inside the box, NOT through Bluetooth, with a mobile app, because
a DIP-switch is absolutely un-hackable.
At any rate, I see a whole lot of beans that are visible to JMX, and I
see that some of them have a whole lot of operations defined, while
others have none. Is there a document somewhere, that will tell me what
these operations actually *do?*
There are documents, but it's easier to browse and read the descriptions
if you connect using e.g. VisualVM and click through them. The documents
are mbeans-descriptors.xml and they exist in each package, so there are
many of them. If you browse via VisualVM (you can just run Tomcat
locally on your desktop and browse them, which may be easier than trying
to figure out how to connect to your running system), all those files
are collated and presented via a GUI.
Back to the IP address. Instead of changing RemoteIPValve from allowing
127.0.0.1 to allowing "anybody" (or whatever), why not just change it to
allow any connection from the controlling machine (where you can connect
via JMX)? You don't need localhost, you just need to know what IP the
commands will appear to be coming from when you want to
stop/start/restart a web application from the command-line.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
