Chris, On Wed, Nov 19, 2025 at 6:28 PM Christopher Schultz < [email protected]> wrote:
> 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. > Yeah, it would fail as is. It might be possible to add an option to make it check the port and if the running process is tomcat just note that tomcat is already running on the port rather than a port binding failure. > > 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"? > Yeah, agreed. I renamed the headings and should have moved it to #3. > > 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. > I could do that, and did propose an option for JNDI connection tests. > > > 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? > I'm fine axing that point for simplicity. The general idea was just that there are lots of recommendations in various places for sensible settings so we could check for those, but the JVM flags may be harder to pull in. > > > * 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. > I actually tried to reduce the proposal to be smaller so that the email wasn't ridiculously long ha Thanks for the feedback ;) > > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
