Tomcat 10.1 STIGing
My place of work prefers DISA STIGed software. I contacted DISA about STIGs for Tomcat 10.1 and they said that the organization that produces the software has to request that it be STIGed. The idea of applyingTomcat 9 STIGs to Tomcat 10.1 was rejected and DISA STIGs are preferable to CIS Benchmarks. Thank you. Leroy Mims
RE: Tomcat 9.0.96 first start throws java.lang.NullPointerException. Works in the same conditions with 9.0.91.
> Looking at "https-openssl-nio-9727" connector (ignoring "http-nio-9728") I see > 24-Oct-2024 12:27:14.109 INFO [main] > org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler > ["https-openssl-nio-9727"] > 24-Oct-2024 12:27:14.156 SEVERE [main] > org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to > initialize component [Connector["https-openssl-nio-9727"]] > org.apache.catalina.LifecycleException: Protocol handler > initialization failed ... > 24-Oct-2024 12:27:45.864 INFO [main] > org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler > ["https-openssl-nio-9727"] > 24-Oct-2024 12:27:50.868 INFO [main] > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > ["https-openssl-nio-9727"] > Thus failed init(), followed by stop() and start(). There is no attempt to > re-run init(). > Looking at org.apache.catalina.util.LifecycleBase, I think that init() > results in LifecycleState.FAILED state, and that there is a bug in the > start() method. > In case of FAILED state the LifecycleState.start() method calls stop() and > goes further to starting. The current issue demonstrates that this behaviour > is wrong. > Maybe make separate error states, INIT_FAILED (aka not initialized), > START_FAILED (not started). Starting a non-initialized component is a bad > idea. > Automatically re-initializing a connector may not work as intended, as there > exist configurations where init() is called with different privileges than > start(). (See "Downgrading user" in > https://commons.apache.org/proper/commons-daemon/jsvc.html Thank you, Konstantin for your analysis and feedback. This confirms what we've experiencing. > The lifecycle you're using could use some double checking, and that's > probably the best way to resolve this. We'll examine the Tomcat > behavior to see if there is a way to improve the robustness, of > course. Re: Rémy's initial (above) recommendation: - our app code already performs a hbws connector bounce when hitting the keystore not found at first start. Then the keystore is found after the restart. But with the refactored tomcat behavior the "https-openssl-nio-9727" connector does not re-initialize itself. Is there a way for our code to call the connector re-init()? Our application hbws logs: _ [2024-10-24 12:27:40,005] INFO 27896[main](com.neverfail.webservices.NFWebServicesServlet) - INIT> hbws servlet [2024-10-24 12:27:40,005] INFO 27896[main](com.neverfail.webservices.tools.Configurator) - KeyStore was not found [2024-10-24 12:27:45,833] WARN 33724[main](com.neverfail.webservices.NFWebServicesServlet) - About to bounce servlet to apply new KeyStore. NFKeystore was just created, servlet should be bounced [2024-10-24 12:27:45,848] INFO 33739[main](com.neverfail.webservices.hbconnection.HBConnectionFacade) - Using groupType:BINARY [2024-10-24 12:27:45,864] INFO 33755[main](com.neverfail.webservices.hbconnection.HBConnectionFacade) - bounceConnector() About to bounce Tomcat connector... [2024-10-24 12:27:45,864] INFO 33755[main](com.neverfail.webservices.hbconnection.HBConnectionFacade) - bounceConnector() Invoking stop on Catalina:type=Connector,port=9727 [2024-10-24 12:27:50,868] INFO 38759[main](com.neverfail.webservices.hbconnection.HBConnectionFacade) - bounceConnector() Invoking start on Catalina:type=Connector,port=9727 [2024-10-24 12:27:50,915] INFO 38806[main](com.neverfail.webservices.tools.Configurator) - KeyStore was found Thank you, /LJ
Re: Tomcat 9.0.96 first start throws java.lang.NullPointerException. Works in the same conditions with 9.0.91.
On Mon, Oct 28, 2024 at 11:41 AM Lucian Jurj wrote: > > > > Looking at "https-openssl-nio-9727" connector (ignoring "http-nio-9728") I > > see > > > 24-Oct-2024 12:27:14.109 INFO [main] > > org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler > > ["https-openssl-nio-9727"] > > 24-Oct-2024 12:27:14.156 SEVERE [main] > > org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to > > initialize component [Connector["https-openssl-nio-9727"]] > > org.apache.catalina.LifecycleException: Protocol handler > > initialization failed > ... > > 24-Oct-2024 12:27:45.864 INFO [main] > > org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler > > ["https-openssl-nio-9727"] > > 24-Oct-2024 12:27:50.868 INFO [main] > > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > > ["https-openssl-nio-9727"] > > > Thus failed init(), followed by stop() and start(). There is no attempt to > > re-run init(). > > > Looking at org.apache.catalina.util.LifecycleBase, I think that init() > > results in LifecycleState.FAILED state, and that there is a bug in the > > start() method. > > > In case of FAILED state the LifecycleState.start() method calls stop() and > > goes further to starting. The current issue demonstrates that this > > behaviour is wrong. > > > Maybe make separate error states, INIT_FAILED (aka not initialized), > > START_FAILED (not started). Starting a non-initialized component is a bad > > idea. > > > Automatically re-initializing a connector may not work as intended, as > > there exist configurations where init() is called with different privileges > > than start(). (See "Downgrading user" in > > https://commons.apache.org/proper/commons-daemon/jsvc.html > > > Thank you, Konstantin for your analysis and feedback. This confirms what > we've experiencing. > > > The lifecycle you're using could use some double checking, and that's > > probably the best way to resolve this. We'll examine the Tomcat > > behavior to see if there is a way to improve the robustness, of > > course. > > Re: Rémy's initial (above) recommendation: > - our app code already performs a hbws connector bounce when hitting the > keystore not found at first start. Then the keystore is found after the > restart. > But with the refactored tomcat behavior the "https-openssl-nio-9727" > connector does not re-initialize itself. > Is there a way for our code to call the connector re-init()? > > Our application hbws logs: > _ > [2024-10-24 12:27:40,005] INFO > 27896[main](com.neverfail.webservices.NFWebServicesServlet) - INIT> hbws > servlet > [2024-10-24 12:27:40,005] INFO > 27896[main](com.neverfail.webservices.tools.Configurator) - KeyStore was not > found > [2024-10-24 12:27:45,833] WARN > 33724[main](com.neverfail.webservices.NFWebServicesServlet) - About to bounce > servlet to apply new KeyStore. NFKeystore was just created, servlet should be > bounced > [2024-10-24 12:27:45,848] INFO > 33739[main](com.neverfail.webservices.hbconnection.HBConnectionFacade) - > Using groupType:BINARY > [2024-10-24 12:27:45,864] INFO > 33755[main](com.neverfail.webservices.hbconnection.HBConnectionFacade) - > bounceConnector() About to bounce Tomcat connector... > [2024-10-24 12:27:45,864] INFO > 33755[main](com.neverfail.webservices.hbconnection.HBConnectionFacade) - > bounceConnector() Invoking stop on Catalina:type=Connector,port=9727 > [2024-10-24 12:27:50,868] INFO > 38759[main](com.neverfail.webservices.hbconnection.HBConnectionFacade) - > bounceConnector() Invoking start on Catalina:type=Connector,port=9727 > [2024-10-24 12:27:50,915] INFO > 38806[main](com.neverfail.webservices.tools.Configurator) - KeyStore was found Ok, so the idea is that init() has to be successful or the component will never become started later on. Connectors are a bit special though. You can use bindOnInit to do the socket bind and TLS start either in init (you don't want it to fail, and you want the server to start accepting asap) or start (which allows stopping and restarting later, new attempts after a failure, and so on). I don't know what the best default behavior after getting into a "failed init" state should be for a component. Right now after destroy, it is not possible to go back and simply call init again. I have the impression this is the most reasonable behavior. Rémy > Thank you, > /LJ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)
That's excellent news. I'll advise the software vendor. Thank you for the update! -Original Message- From: Mark Thomas Sent: Friday, October 25, 2024 4:20 PM To: users@tomcat.apache.org Subject: Re: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All) On 11/10/2024 01:05, Eric Robinson wrote: > Mark, > > Thanks very much for the update. We'll check back in November! I've just committed the fix. It should be in the next set of releases (November). Mark > > -Eric > > > -Original Message- > From: Mark Thomas > Sent: Thursday, October 10, 2024 5:30 PM > To: users@tomcat.apache.org > Subject: Re: Database Connection Requests Initiated but Not Sent on > the Wire (Some, Not All) > > Eric, > > My apologies. I dropped the ball on this one. I've just re-read the thread to > remind myself of the details. I'm aiming to get this fixed for the November > release round. > > Mark > > > On 10/10/2024 10:10, Eric Robinson wrote: >> Hi Mark, >> >> Just following up on this. Did you arrive at the long-term solution? This >> issue is still biting us. >> >> >> -Original Message- >> From: Eric Robinson >> Sent: Thursday, May 30, 2024 4:15 PM >> To: Tomcat Users List >> Subject: RE: Database Connection Requests Initiated but Not Sent on >> the Wire (Some, Not All) >> >> Hi Mark, >> >>> -Original Message- >>> From: Mark Thomas >>> Sent: Thursday, May 30, 2024 9:30 AM >>> To: users@tomcat.apache.org >>> Subject: Re: Database Connection Requests Initiated but Not Sent on >>> the Wire (Some, Not All) >>> >>> OK. >>> >>> This is an interim binary patch for 9.0.80 only. >>> >>> The purpose is to: >>> - confirm the proposed change fixes the problem >>> - provide you with a workaround in the short term >>> >>> This is the binary patch: >>> >>> https://people.apache.org/~markt/dev/classloader-not-found-cache-9.0. >>> 8 >>> 0- >>> v1.zip >>> >>> Extract the contents into $CATALINA_HOME/lib >>> >>> You should end up with: >>> >>> $CATALINA_HOME/lib/org/apache/... >>> >> >> I'll get on this right away. >> >>> Usual caveats apply. This is not an official release. Use it at your >>> own risk. Don't blame either me or the ASF it is results in alien >>> invasion, a tax bill, the server catching fire or anything else unexpected >>> and/or unwanted. >>> >> >> Okay, but if we're invaded by alien tax collectors riding flaming servers, >> THEN I'm coming after you. >> >>> Longer term, I'm not sure this is exactly how I want to fix it in >>> Tomcat. I am convinced of the need to cache classes that don't exist >>> but exactly where / how to do that and what degree of control the user >>> should have is very much TBD. >>> >>> I suspect this will be a topic of discussion at Community Over Code >>> at Bratislava next week. >>> >>> I am expecting that any fix won't be in the June release round but >>> should be in the July release round. >>> >>> Let us know how you get on and good luck. >>> >> >> Will do! >> >> >>> Mark >>> >>> >>> On 30/05/2024 10:16, Mark Thomas wrote: On 29/05/2024 17:03, Eric Robinson wrote: > One of the webapps is related to voice reminder messages that go > out to people. The reminders go out sometime after 9 am, which > tracks with the slowdowns. Ack. Something to try while I work on a patch is setting archiveIndexStrategy="bloom" on the resources. You'd configure that in META-INF/context.xml something like this: Mark --- - - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >>> - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> Disclaimer : This email and any files transmitted with it are confidential >> and intended solely for intended recipients. If you are not the named >> addressee you should not disseminate, distribute, copy or alter this email. >> Any views or opinions presented in this email are solely those of the author >> and might not represent those of Physician Select Management. Warning: >> Although Physician Select Management has taken reasonable precautions to >> ensure no viruses are present in this email, the company cannot accept >> responsibility for any loss or damage arising from the use of this email or >> attachments. >> Disclaimer : This email and any files transmitted with it are confidential >> and intended solely for intended recipients. If you are not the named >> addressee you should not disseminate, distribute, copy or alter this email. >> Any views or opinions presented in this email are solely those of the author >> and might not represent those of Physician Select Management. Warning: >>
