Hi all, 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. 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 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 * 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? Thanks, Coty
