RE: APR libs present but not found
Hi Christopher, I needed to build the APR libs from source as there was no rpm in yum, but the default directory where the libs were place was not in the Java path, and so once I noticed that and added that directory to the path in setenv.sh APR is found and used. Thanks -John -Original Message- From: Christopher Schultz Sent: Friday, September 6, 2019 2:37 PM To: users@tomcat.apache.org Subject: Re: APR libs present but not found -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 John, On 9/6/19 16:51, John Beaulaurier -X (jbeaulau - ADVANCED NETWORK INFORMATION INC at Cisco) wrote: > Hello, > > I installed the following RPMs via Yum for OpenSSL support > > RHEL 7.4 apr.i686 > 1.4.8-3.el7_4.1 apr.x86_64 > 1.4.8-3.el7_4.1 apr-devel.i686 > 1.4.8-3.el7_4.1 apr-devel.x86_64 > 1.4.8-3.el7_4.1 > > When I test with Tomcat 7.x or 9.x the log notes the APR native libs > could not be found in the java library path, when they are in the java > library path located at /lib64 and /lib in the OS file system. > > What am I missing? Can you post the startup log where Tomcat says it "cannot find the APR library"? It should include the set of paths it's checking for those files. Note that both the APR connector AND the OpenSSL-based JSSE connector require both libtcnative and libapr in the library path. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl1y0YMACgkQHPApP6U8 pFicOBAAgkpDPq3C805og14AZcCoZ/31VMT4S4YdYCfRMGabnECULuxvM015Lcdi 4o5IG1rDJVivHxyeY8PU2zLbpwL7b4nOuEDSYteJygfbb2xCEOedcSE2PeKBmyj1 nuTDj08bvtXFCN+5k8hv31/ffu2+ZjCffagfQkMxeDG7MmJuLVwN9WIfokO0pEFO Gq++EdBxTptYAB6UHKDdS9nulpSK6XU8fUP0KmYzCc6w0w2TTToAhHF0OkRiAjyq egPjBjarglhKUOJH+IADaS4g264qbEZ5Xbtgtws54jKmgEPpc9X8bcOt/EH9Tp0X 7CCCDViwVVjOxrDI7p17GYrEeTBq5qZx2QmhlGmsTTpR1O5C3BIBsPBaasioP6tC CYRJ3xX7FW+iUTQxqnU9KyzoyfnQ1C+rQjGN0q8vkx+UrmMgSW8CwQAlboiSuGIM OnqAXkOpfajNveLmBKORBcrxjzgIrHUkLiy3G3qI+qWQrHetbV6q3sE937lTFnhY lphohR55W0ZkjhWYsVbCa/zAcguKF3xIYjcY5ErD+BKDH/kRaWLKHkR8DbQkEzq5 bFNoO+v9izVMWr13qEERBYXENxQyGRnJOk9KvkW+rLeCVyKdWLHyeeuLGy91gu80 ou6Hzk5ZNwWV70E5Nl3M9I3dx+UOFlTs2YG2UpYHe5GrPmOiNW8= =PlDO -END PGP SIGNATURE- - 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
Re: SSO fails on Tomcat 9
On 10/09/2019 16:47, André Warnier (tomcat) wrote: > On 10.09.2019 15:38, Mark Thomas wrote: >> On 06/09/2019 13:20, Heidi Leerink - Duverger wrote: >>> Hello Mark, >>> >>> That helps somewhat, my browser now shows the login page for our >>> application, BUT I do not get my username in HTTP variable >>> REMOTE_USER but the principal keytab related name. >>> >>> So instead of hduverge I get HTTP/nlsl-decadetst.u4agr.com@U$AGR.COM >> >> The Tomcat Authenticator takes care of validating the user. In the >> configuration you provided the JAASRealm is - effectively - >> (re-)validating the contents of the keytab file. That is why you see the >> keytab principal as the authenticated user. >> >> Try replacing the JAASRealm with the AuthenticatedUserRealm. Something >> like: >> >> > allRolesMode="authOnly" > > Mmm. That looks like a typo, likely to confuse this OP even more, no ? Yep. Copy paste error. Should be: Tx. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSO fails on Tomcat 9
On 10.09.2019 15:38, Mark Thomas wrote: On 06/09/2019 13:20, Heidi Leerink - Duverger wrote: Hello Mark, That helps somewhat, my browser now shows the login page for our application, BUT I do not get my username in HTTP variable REMOTE_USER but the principal keytab related name. So instead of hduverge I get HTTP/nlsl-decadetst.u4agr.com@U$AGR.COM The Tomcat Authenticator takes care of validating the user. In the configuration you provided the JAASRealm is - effectively - (re-)validating the contents of the keytab file. That is why you see the keytab principal as the authenticated user. Try replacing the JAASRealm with the AuthenticatedUserRealm. Something like: Mmm. That looks like a typo, likely to confuse this OP even more, no ? Note: This Realm should *only* be used with Authenticators like org.apache.catalina.authenticator.SpnegoAuthenticator that authenticate the user since this Realm simply takes the information provided and assumes it is valid. 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
Re: SSLHostConfig configuration
On Tue, Sep 10, 2019 at 5:38 AM Mark Thomas wrote: > On 10/09/2019 13:14, Herb Burnswell wrote: > > > > > My apologies for my ignorance here, when you say 'configured on the > > SSLHostConfig' are you saying it should NOT be in this block: > > > > > > > > > > > > > > certificateKeystoreFile="/app/config/keystore.p12" > > certificateKeyAlias="example_wildcard" > > certificateKeystorePassword="maskedpasswd" > > truststoreFile="/app/config/truststore.p12" > > truststorePassword="maskedpasswd" > > type="RSA"/> > > > > > > > > > > > > This is how I tried to configure it and we still receive the > "trustAnchors > > parameter must be non-empty" error. Can you clarify where you mean the > > truststore directives should be defined? > > > You need to move the trust store config from the Certificate to the > > SSLHostConfig like this: > > > >hostName="*.example1.com" > >truststoreFile="/app/config/truststore.p12" > > truststorePassword="maskedpasswd" > >> > > > >certificateKeystoreType="PKCS12" > >certificateKeystoreFile="/app/config/keystore.p12" > >certificateKeyAlias="example_wildcard" > >certificateKeystorePassword="maskedpasswd" > >type="RSA" > >/> > > > > > > Mark > Thank you Mark, that appears to have done the trick. Greatly appreciated.. HB > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: SSO fails on Tomcat 9
On 06/09/2019 13:20, Heidi Leerink - Duverger wrote: > Hello Mark, > > That helps somewhat, my browser now shows the login page for our application, > BUT I do not get my username in HTTP variable REMOTE_USER but the principal > keytab related name. > > So instead of hduverge I get HTTP/nlsl-decadetst.u4agr.com@U$AGR.COM The Tomcat Authenticator takes care of validating the user. In the configuration you provided the JAASRealm is - effectively - (re-)validating the contents of the keytab file. That is why you see the keytab principal as the authenticated user. Try replacing the JAASRealm with the AuthenticatedUserRealm. Something like:
Re: SSLHostConfig configuration
On 10/09/2019 13:14, Herb Burnswell wrote: > My apologies for my ignorance here, when you say 'configured on the > SSLHostConfig' are you saying it should NOT be in this block: > > > > > > certificateKeystoreFile="/app/config/keystore.p12" > certificateKeyAlias="example_wildcard" > certificateKeystorePassword="maskedpasswd" > truststoreFile="/app/config/truststore.p12" > truststorePassword="maskedpasswd" > type="RSA"/> > > > > > > This is how I tried to configure it and we still receive the "trustAnchors > parameter must be non-empty" error. Can you clarify where you mean the > truststore directives should be defined? You need to move the trust store config from the Certificate to the SSLHostConfig like this: Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSLHostConfig configuration
On Tue, Sep 10, 2019 at 3:46 AM Mark Thomas wrote > > > > >> Questions: > >> > >> 1. What has changed in between Tomcat 8.5.32 --> 8.5.40 that seemingly > now > >> requires truststore information in this connector configuration? > > > There have have been several changes aimed at making it easier to switch > > between JSSE and OpenSSL based TLS implementations. Tomcat tries to > > store all provided keys and certs in an in-memory Java keystore and then > > provides the connectors with the keys and certs in the format they > > require. With the wide range of keystores and key formats there have > > been a few edge cases where the translation process broke. This looks > > like one of them. > > > There are additional fixes in later 8.5.x releases so you may wish to > > try one of those. > > Thank you for the information. As far as using a newer version of Tomcat with fixes, we want to go with the 8.5.40 version that is packaged with the application for support reasons. > >> 2. What needs to be done to allow this to work in the 8.5.40 Tomcat > version? > > > truststoreFile and truststorePassword should be configured on the > > SSLHostConfig not on the Certificate element. > My apologies for my ignorance here, when you say 'configured on the SSLHostConfig' are you saying it should NOT be in this block: This is how I tried to configure it and we still receive the "trustAnchors parameter must be non-empty" error. Can you clarify where you mean the truststore directives should be defined? Thanks again, HB > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: POST request fails if content is ignored?
Very grateful for your reply, this does indeed solve my issue (and I learned something new too). Thanks, Leon On 10/09/2019 12:03, Mark Thomas wrote: > On 09/09/2019 16:41, Leon Atherton wrote: >> Our use case is rejecting the request based on IP. >> >> In the browser the status code is 0, and the network tab in developer >> tools is showing no response to the request. It's the same in Chrome and >> Firefox. >> >> The request works fine when I send from Node.JS. >> >> It seems to me that Tomcat responds to the request before the upload has >> completed, and calling request.getParameter() fixes the problem because >> it causes Tomcat to read the full request before the response is sent. >> >> Some clients are fine with the early response (e.g. Node.JS), but both >> Chrome and Firefox don't like it. >> >> I'm not sure if it's an issue with how Tomcat handles the request, or >> how the browsers are handling the response (but I suspect it can be >> fixed on the Tomcat side as the problem does not occur with Payara). > The configuration attribute you want is maxSwallowSize. You need to set > that to greater than the size of the uploaded file. > > Clients could handle this better but many don't read the response until > the request is fully written. > > Tomcat limit's maxSwallowSize as a DoS protection measure. Without it, a > client could just continue uploading a slow trickle of data and tie up a > server thread. > > For the record, maPostSize applies *only* to requests using > application/x-www-form-urlencoded > > The test provided by the OP uses multipart/form-data. The applicable > limits are defined by javax.servlet.annotation.MultipartConfig and the > defaults are unlimited. > > Any call to getPart(), getParameter() and friends will trigger the > reading of the request body. > > Hence, without the call to getParameter() Tomcat doesn't read the > request body. With small uploads there is enough network buffering > between the client and the server for the client to be able to write the > full request so it reads the response. (Tomcat's maxSwallowSize > effectively acts as a buffer.) With larger uploads the client fills the > buffers before the request is fully written so it never sees the response. > > Increasing the maxSwallowSize will allow the client to write the full > request and then read the response. > > 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
Re: POST request fails if content is ignored?
On 09/09/2019 16:41, Leon Atherton wrote: > Our use case is rejecting the request based on IP. > > In the browser the status code is 0, and the network tab in developer > tools is showing no response to the request. It's the same in Chrome and > Firefox. > > The request works fine when I send from Node.JS. > > It seems to me that Tomcat responds to the request before the upload has > completed, and calling request.getParameter() fixes the problem because > it causes Tomcat to read the full request before the response is sent. > > Some clients are fine with the early response (e.g. Node.JS), but both > Chrome and Firefox don't like it. > > I'm not sure if it's an issue with how Tomcat handles the request, or > how the browsers are handling the response (but I suspect it can be > fixed on the Tomcat side as the problem does not occur with Payara). The configuration attribute you want is maxSwallowSize. You need to set that to greater than the size of the uploaded file. Clients could handle this better but many don't read the response until the request is fully written. Tomcat limit's maxSwallowSize as a DoS protection measure. Without it, a client could just continue uploading a slow trickle of data and tie up a server thread. For the record, maPostSize applies *only* to requests using application/x-www-form-urlencoded The test provided by the OP uses multipart/form-data. The applicable limits are defined by javax.servlet.annotation.MultipartConfig and the defaults are unlimited. Any call to getPart(), getParameter() and friends will trigger the reading of the request body. Hence, without the call to getParameter() Tomcat doesn't read the request body. With small uploads there is enough network buffering between the client and the server for the client to be able to write the full request so it reads the response. (Tomcat's maxSwallowSize effectively acts as a buffer.) With larger uploads the client fills the buffers before the request is fully written so it never sees the response. Increasing the maxSwallowSize will allow the client to write the full request and then read the response. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSLHostConfig configuration
On 09/09/2019 23:28, Herb Burnswell wrote: > Questions: > > 1. What has changed in between Tomcat 8.5.32 --> 8.5.40 that seemingly now > requires truststore information in this connector configuration? There have have been several changes aimed at making it easier to switch between JSSE and OpenSSL based TLS implementations. Tomcat tries to store all provided keys and certs in an in-memory Java keystore and then provides the connectors with the keys and certs in the format they require. With the wide range of keystores and key formats there have been a few edge cases where the translation process broke. This looks like one of them. There are additional fixes in later 8.5.x releases so you may wish to try one of those. > 2. What needs to be done to allow this to work in the 8.5.40 Tomcat version? truststoreFile and truststorePassword should be configured on the SSLHostConfig not on the Certificate element. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9.0.16 Packaging Change (Extras)
On 10/09/2019 09:41, Stephen Hames wrote: > Hi All, > > After Tomcat 9.0.14, the packaging available for download seems to have > changed in that the bin/extras directory has been removed. > > I am finding a bit of confusion on this. We use catalina-jmx-remote.jar > and previously this was included in the extras directory. > > I saw an entry in the change log about merging the extras back into core. > But am unclear on expected the expected bahaviour now. > > Is this meant to be that it is no longer necessary to add these jars, or > that we need to source them via alternative means? It should be unnecessary to add the JARs as the classes should be in catalina.jar. > Using tomcat 9.0.22, if I add the catalina-jmx-remote.jar from 9.0.14, it > seems to work as normal, but if I don't add the jar, it does not. Can you share the steps you are following and the test you are using so we can see if we can reproduce this. I've checked the build and the classes are present in catalina.jar Thanks, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat doesn't refreshes and still gives me an old error again and again
Eclipse works the way it works, but what you can use is
https://marketplace.eclipse.org/content/eclipse-tomcat-plugin which is
basically an update of the mighty
http://www.eclipsetotale.com/tomcatPlugin.html
I use a blank dynamic web project, with a standard plugin setup, ie default
output folder ../../WEB-INF/classes. I then fudge the WEB-INF/lib folder
by using a maven task to copy the jars from my war build process. The
devloader is good but I could not find a way to play nicely with maven.
You then use the debugging as part of the plugin.
copy-webapp-jars
maven-compiler-plugin
3.8.0
1.8
1.8
false
default-compile
none
org.apache.maven.plugins
maven-dependency-plugin
3.1.1
copy-dependencies
package
copy-dependencies
${project.basedir}/src/main/webapp/WEB-INF/lib
false
false
true
provided
junit,org.hamcrest
org.apache.maven.plugins
maven-antrun-plugin
1.8
clear-jars
prepare-package
run
On Wed, 4 Sep 2019 at 14:21, Karen Goh wrote:
> Hi Expert,
>
> I am facing this problem - that Tomcat - 9.0.24 doesn't refreshes and it
> will give ma an error, even after I commented out a line. But, after
> several cleaning - using Tomcat Directory clean, right-click on the project
> in Eclipse and do a run maven force update and project built, it will still
> give me an error that point out to a commented out line.
>
> Can I know if the above indicate a corrupted Tomcat instance or what
> should I do in order not to have the above problem crop up again and again?
>
> Eclipse
> Maven Java EE, JSP, JSTL
> OS : Windows10
> Tomcat : 9.0.24
>
> Thanks & regards,
> Karen
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Tomcat 9.0.16 Packaging Change (Extras)
Hi All, After Tomcat 9.0.14, the packaging available for download seems to have changed in that the bin/extras directory has been removed. I am finding a bit of confusion on this. We use catalina-jmx-remote.jar and previously this was included in the extras directory. I saw an entry in the change log about merging the extras back into core. But am unclear on expected the expected bahaviour now. Is this meant to be that it is no longer necessary to add these jars, or that we need to source them via alternative means? Using tomcat 9.0.22, if I add the catalina-jmx-remote.jar from 9.0.14, it seems to work as normal, but if I don't add the jar, it does not. Thanks. Regards, Stephen -- This message may contain confidential and privileged information. If it has been sent to you in error, please reply to advise the sender of the error and then immediately delete this message.
Re: Tomcat doesn't refreshes and still gives me an old error again and again
On 06/09/2019 15:36, Karen Goh wrote:
>
>
>
>
>
> On Thursday, September 5, 2019, 9:47:40 PM GMT+8, Mark Thomas
> wrote:
>
>
> Personally, I gave up on using Tomcat and Eclipse in this way a long
> time ago. It is a little more work but I run a completely separate
> Tomcat instance and then use the "Export...", "WAR file" option to
> deploy the latest version of my webapp to the external Tomcat instance
> and then let Tomcat's auto-deploy take care of things.
>
> Hi Mark,
>
> This is completely new to me. When you said use the "Export" are you
> referrring to the Export inside Eclipse?
Yes. Eclipse will export a dynamic web project to a WAR file.
> How do you debug without Eclipse then ?
I still use Eclipse. I connect to the Tomcat process using remote
debugging and debug my way through Tomcat and/or the web application as
necessary.
Mark
>
> Apart from those times where I've managed to export to the wrong Tomcat
> instance (entirely my own fault) I've never had an issue.
>
> As an added bonus it makes it easy to debug into the Tomcat code when I
> need to but I accept that that is something a Tomcat developer is going
> to want to do rather more frequently than someone developing a web app.
>
> Mark
>
>> Karen,
>>
>> On 9/4/19 10:45, Karen Goh wrote:
>>> On Wednesday, September 4, 2019, 9:32:43 PM GMT+8, Dave Thorn
>>> wrote:
>>
>>
>>> On Wed, Sep 04, 2019 at 01:21:11PM +, Karen Goh wrote:
>>
>>
I am facing this problem - that Tomcat - 9.0.24 doesn't
refreshes and it will give ma an error, even after I commented
out a line. But, after several cleaning - using Tomcat Directory
clean, right-click on the project in Eclipse and do a run maven
force update and project built, it will still give me an error
that point out to a commented out line.
>>
>>
>>> Do you have a tomcat/work directory? ISTR sometimes having to
>>
>>> rm -rf /var/cache/tomcat/work/Catalina/localhost/{webappname}
>>
>>> Could you let me know how to do it Windows 10 way? Sorry for the
>>> trouble cos basically most of my stuff is still using Windows
>>> 10
>>
>> C:> DEL /S %CATALINA_BASE%\work\Catalina\localhost\{webappname}
>>
>> Or just navigate Windows Explorer to the "work" directory and press
>> the "DELETE" key on your keyboard.
>>
>> Hi Chris,
>>
>> Just to clarify, so instead of doing the clean, I will have to to to this
>> place - C:\Program Files\Apache\apache-tomcat-9.0.24\webapps\webappname and
>> delete weappname ?
>>
>> I happened to read this
>> https://stackoverflow.com/questions/763693/where-is-the-work-directory-located-for-a-tomcat-instance-running-in-eclipse
>>
>> I checked the location when I right-clicked the Tomcat instance, it says
>> meta data, so should I delete the metadata one ? My Tomcat configuration is
>> take control of Tomcat installation.
>>
>> Kindly advise. And thanks for your help.
>>
>>
>>
>>
>> -chris
>>
>>
>> -
>> 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
>
>
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows registry entry missing on Tomcat Silent install - 9.0.20
On 09/09/2019 15:33, Mark Thomas wrote: > On 06/09/2019 07:26, Pradeep Kumar M N wrote: >> Hi All, >> >> I am using Tomcat 9.0.20. I am installing the Tomcat silently from a >> PowerShell script. But after silent installation, below mentioned registry >> entry seems not added. I am passing a Config ini file to tomcat installer >> with /C option. This issue is only present when I pass the /C parameter. >> When I don't pass the parameter, registry entry seems to be added correctly >> in registry. >> >> HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat\9.0 >> >> apache-tomcat-9.0.20.exe /C=< tomcatConfig.ini file path> /S /D=> path> >> >> Below is the entry present in tomcatConfig.ini >> JavaHome=$javaHomeEnv >> >> >> Has one any encountered this issue ? > > Running tests locally, it appears that when running a silent install the > registry entries are added under the Wow6432Node rather than under the > normal 64-bit location. Still trying to figure out why this is. Found it. Will be fixed in the next round of releases (due shortly for 9.0.x and 8.5.x). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
