Coty,
On 11/19/25 2:18 PM, Coty Sutherland wrote:
I've thought of another user/developer experience improvement that might be
interesting to the community: enhancing the configtest to do more
comprehensive checks/validations. The current version of configtest
validates the server.xml syntax by firing up a startup and exiting, but
doesn't catch some of the configuration issues that you might face at
runtime nor does it check to see if the server is configured in a way that
matches our documented best practices and suggestions.
This has me thinking: I've certainly wanted to use "foo-serverd
configtest" without taking down the running server before. For example,
something where you want MINIMAL downtime but had to make a significant
change to the primary config. So before taking down the WORKING server,
I want to check that I'll be able to start it up again with the new
configuration.
My guess is that configtest would currently fail with "cannot bind to
port". I wonder what options exist for allowing the ports to float for
this configtest specifically. I know many components in Tomcat can be
configured to find the "first port available over N" but I don't know
the details. If one of the configtest options could be "strict vs.
sloppy port checking" or something, that would be really fantastic.
My proposal is to> add more validation that checks configuration for
correctness, security, and best practices before starting Tomcat.
I've created three buckets/classifications of improvements I'd like
feedback on:> > 1. Prevent startup failures and security vulnerabilities (High
impact)
* Port and File Validation to detect port conflicts; verify file existence
(keystores and drivers) & permissions; check SSL cert expiration and warn
if <30 days
* XML Validation to validate against tomcat schemas; detect/suggest fixes
for deprecated elements and typos
* Basic JNDI Validation to ensure the drivers are in the classpath and
validate the connection pool sanity
* Security improvements to detect default credentials; check manager app
access controls; verify AJP connectors utilize secrets; warn about
world-readable configs
I'm not sure "detect/suggest fixes for deprecated elements" belongs
under the "startup and security" heading. Maybe demote this specifically
to another mode of operation like "lint"?
To check for files-available, you might want to try to check out a
connection from any JDBC resource(s) that are defined. Many times, the
driver connection URLs include filenames that point to things like TLS
trust stores, etc.
Note: Yes, some of these things are done currently, but the output is just
a regular server startup so I think it could be formatted to better convey
issues.
2. Production hardening (Medium impact)
* SSL/TLS checks to validate certificates, detect deprecated protocols and
weak cipher suites
* Configuration improvements to validate heap size vs RAM, deprecated JVM
flags, and connector thread pool sizing/timeouts
This seems like a deep rat hole to me -- specifically the "deprecated
JVM flags". This is also probably not very future-proof. Maybe have a
JVM version cap for the check, so it doesn't check for JVMs it hasn't
been specifically programmed to validate?
* Cross-component validation like ensuring jvmRoute is defined when
clustering
* Deployment & JNDI improvements to review authDeploy and reloadable
settings; detect security risks like .git in webapps; optionally test JNDI
connections
3. Optimizations and developer experience improvements (Lower impact; nice
to haves)
* Performance tuning recommendations like thread pool sizing suggestions,
etc
* Cleanup step to detect duplicate jars, unused configs, webapps that
aren't configured for deployment (orphaned)
* Reporting added format the output in a more direct way; option to
generate HTML or maybe JSON reports; add verbose mode with detailed
explanations of recommendations, etc
After writing all of that out, maybe this should be a separate tool instead
of enhancements to configtest or we should incorporate some of the checks
into a pre-startup step in the boot process? Thoughts?
A separate tool does make sense to me if you already plan on the large
feature set shown above. I can only guess it will continue to metastasize.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
