Re: OT: Question about TomcatX.exe files
See also : https://cwiki.apache.org/confluence/display/TOMCAT/Windows#Windows-Q11 On 28.09.2022 21:41, jonmcalexan...@wellsfargo.com.INVALID wrote: Thank you Mark. I mainly wanted to have answers for when I will be invariably questioned about it. :-). I knew about the naming, but understand that these aren't recompiled for each release, so modifying the version wouldn't work. (file/properties) Thanks, Dream * Excel * Explore * Inspire Jon McAlexander Senior Infrastructure Engineer Asst. Vice President He/His Middleware Product Engineering Enterprise CIO | EAS | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: Mark Thomas Sent: Wednesday, September 28, 2022 1:57 PM To: users@tomcat.apache.org Subject: Re: OT: Question about TomcatX.exe files On 28/09/2022 18:36, jonmcalexan...@wellsfargo.com.INVALID wrote: Ok, this is a silly off-topic question, but is there an underlying reason that the wrapper exe files for Windows Tomcat do not reflect the same file version as the implementation version found in the manifest of the bootstrap.jar? That version info matching the release version of the Tomcat release? I understand if these wrappers aren't recompiled each release, but if they are, why not make the versions reflect the Tomcat release? This seems to throw a loop at 3rd party software discovery tools such as BigFix, ServiceNow, etc., as well as normalizations performed by vendors like Flexera. Those files are renamed Procrun files from Commons Daemon. The filesare never compiled as part of a Tomcat release (we use the binaries from Commons Daemon) but they can be renamed to anything you want but note the next point. The file name reflects the default service name so you don't have to specify the service name every time you call the executables. The default service name is TomcatX where X is the major version. This allows the service name to stay the same across minor and point release upgrades. Renaming the service every time you upgrade is likely to cause other issues - e.g. for software monitoring the service. Other naming schemes are possible. The current scheme seems to provide a reasonable solution for the majority of users. That said, if the community disagrees, it can always be changed. Mark Just curious. Thank you for your time. Dream * Excel * Explore * Inspire Jon McAlexander Senior Infrastructure Engineer Asst. Vice President He/His Middleware Product Engineering Enterprise CIO | EAS | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com> This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - 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: tomcat logging
Hi Alan,
On 09.06.22 12:56, Alan F wrote:
> Tomcat logging
>
> I would like to add a delimiter or characters " " around {user-agent} for
> logging, I wanted it in double quotes for example "Mozilla 5.0.." but can't
> seem to make it work. Or even adding a # symbol before would help any ideas?
I assume, you refer to access logging. Recent Tomcat has a proper example
already in the standard server.xml (IIRC for a long time), just use the
XML
entity, where you need it (taken from 9.0.64):
If you are happy with a standard combined pattern, just use pattern="combined",
it contains user agent in double quotes.
See https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Access_Log_Valve
for complete pattern information.
hth,
Thomas
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session stickiness with mod_proxy_balancer
Hi Chris. Maybe the problem was due to this : https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxy the snippet after "Mixing ProxyPass settings in different contexts does not work:" In your first configuration below, the ProxyPass (including the settings of the variables) is outside of any , or block, while the other proxy-related directives are inside a block; those are 2 different "contexts". (And clearly, the "does not work" could have been a bit more explicit; as it is, it sounds like my customers reporting issues). Alternatively, the difference between the 2 configurations may be due to a question of priority (or "overriding"). Apache httpd considers content at a different time (in the HTTP request cycle) compared to what is contained in sections (and thus probably also sections), and compared to what is not contained in any section (and which is thus considered as "VirtualHost-level"). Within each section, the interpretation is generally top-down. In your 1st configuration below, I notice that the ProxyPass directive is *after* the block, while in the example at https://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html#balancer_manager , the ProxyPass directive *precedes* the block. That may sound insignificant or finicky as a difference, but actually, based on https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#workers, this second explanation may be the right one : If I understand that page correctly, - if your block comes first (before the ProxyPass), then it is the block which creates the "balancer:" worker. And then, when the ProxyPass is evaluated, not only does it "re-use" that same worker, but also the attributes of the ProxyPass are ignored. (quote: "Note that all configuration attributes given explicitly for the later worker will be ignored")(It also says "This will be logged as a warning", so if you still have access to the old log, you could check) - while if the ProxyPass directive comes before the block, then it is the ProxyPass which creates the worker (and the attributes are not ignored). And when the is evaluated, it "re-uses" the worker created by ProxyPass (with its already-defined attributes). The same logic also explains why your 2d configuration does work : - the block creates the "balancer" worker AND sets its attributes via ProxySet - the ProxyPass directive comes after, and it re-uses the "balancer" worker, but it does not set parameters (which would be ignored anyway, with a warning logged) This could be easily confirmed (or negated) if you had a chance to restore your first configuration, and just moved the ProxyPass above the block. (But in the end, I believe that your 2d configuration is more "solid" anyway). In the end, each httpd add-on module (like mod_proxy and mod_proxy_balancer) is responsible for its own interpretation (and ordering) of the directives that relate to it, and they are not always totally consistent with one another in that respect. For even more sordid details, see https://httpd.apache.org/docs/2.4/sections.html and its sections : - How the sections are merged and - Relationship between modules and configuration sections and if after that you really understand what is going on, come back to me to explain, because after 20+ years of configuring Apache httpd, I'm still not sure sometimes. On 22.12.2021 18:04, Christopher Schultz wrote: All, I'm setting up mod_proxy_balancer to talk to Tomcat after having only used mod_jk for a very long time. With a multiple-Tomcat-node situation, I was finding that sessions didn't seem to be "sticking" and I thought I had my configuration correct. Something like this: BalancerMember https://tomcat-1/ route=tc1 BalancerMember https://tomcat-2/ route=tc2 ProxyPass /myapp/ balancer://myapp/ stickysession=JSESSIONID|jsessionid scolonpathdelim=On ProxyPassReverse /myapp/ balancer://myapp/ I found that httpd wasn't picking-up my session ids from JSESSIONID cookies like 76234132976549238.tc1 or 642586735782.tc2. However, when I *moved* the configuration from the ProxyPass line into the balancer configuration like this, it works as expected: BalancerMember https://tomcat-1/ route=tc1 BalancerMember https://tomcat-2/ route=tc2 ProxySet stickysession=JSESSIONID|jsessionid scolonpathdelim=On ProxyPass /myapp/ balancer://myapp/ ProxyPassReverse /myapp/ balancer://myapp/ Was I incorrect in my expectations? I would expect that the two configurations would work the same way. This is a client system so I can't really play around with it too much at this point. Once it started working, we stopped messing-around with it. I can probably create another similar setup but it will take me a while to do so; if anyone can explain what I'm seeing without me having to reproduce it, t
Re: IIS 10.0 as Tomcat reverse proxy does not send auth_type and remote_user AJP heder
Sorry, I haven't read the whole thread, but a basic question :
In the tomcat AJP Connector configuration, is "tomcatAuthentication" set to
"no" ?
https://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html#Common_Attributes
On 13.07.2021 17:35, Paolo Clerici wrote:
I don't see any ISAPI redirector set up there. I was expecting to see
something like the steps described here:
http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html
Yes, if I have not missed something, I think I have done everything
that is written in the document.
The only differences are that there are two sites "prod" and "test" so
the only differences for "test" are:
1) Dll folder: C:\Apache Software Foundation\Jakarta Isapi Redirector\test\bin
2) ISAPI filter name: "Jakarta Connector test" (not "tomcat")
isapi_redirect.properties file content:
extension_uri=/jakarta/isapi_redirect.dll
log_file=C:\Apache Software Foundation\Jakarta Isapi
Redirector\test\log\mod_jk.log
log_level=warn
worker_file=C:\Apache Software Foundation\Jakarta Isapi
Redirector\test\conf\workers.properties
worker_mount_file=C:\Apache Software Foundation\Jakarta Isapi
Redirector\test\conf\uriworkermap.properties
workers.properties file content:
worker.list=dgroupnex02,dgroupnex01
worker.dgroupnex02.type=ajp13
worker.dgroupnex02.host=10.1.2.93
worker.dgroupnex02.port=8009
worker.dgroupnex01.type=ajp13
worker.dgroupnex01.host=10.1.2.39
worker.dgroupnex01.port=8009
uriworkermap.properties file content:
/S2W/*=dgroupnex02
/s2wweb/*=dgroupnex01
/websat/*=dgroupnex02
I would like to tell you that ISAPI redirection of all virtual folders
works perfectly. The only thing that doesn't work is sending the
authorization type and user from IIS to Tomcat.
The only application that needs this functionality is "s2wweb".
Thanks,
Paolo
Il giorno mar 13 lug 2021 alle ore 14:44 Mark Thomas
ha scritto:
On 13/07/2021 12:29, Paolo Clerici wrote:
Hi Mark,
How did you set up the s2wweb virtual directory?
Physical Path: C:\Apache Software Foundation\virtual\test\s2wweb
Physical Path Credential: blank
Physical Path Credential Logon Type: Clear Text
Virtual Path: /s2wweb
Pass-through authentication: / Connect As: / Path credentials:
Application user (pass-through authentication)
I don't see any ISAPI redirector set up there. I was expecting to see
something like the steps described here:
http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html
Mark
Thanks,
Paolo
Il giorno mar 13 lug 2021 alle ore 10:27 Mark Thomas
ha scritto:
On 13/07/2021 08:49, Paolo Clerici wrote:
Hi Mark,
Are you connecting from a machine that isn't part of the Windows AD?
I have tried both from PCs connected to AD and from PCs not connected to AD.
Normally, I'd expect authentication to work without any password prompt.
If I connect from PC AD I am not asked for credentials (correct). If I
connect from a non-AD PC I am prompted for credentials (correctly).
The credential check is done correctly by IIS.
Are any other authentication mechanisms enabled?
For virtual directory "s2wweb" only "Windows Authentication" is
enabled ("Anonymous Authentication" is disabled). For site "test" is
enabled "Anonymous Authentication".
Are your two test machines (working and not working) connecting to the
same Tomcat instance (and on the same port)?
Yes.
Current IIS server needs to be migrated to a new IIS server. The
current server (Windows Server 2008 R2 with IIS 6.1) is connected to
the same Tomcat server (another Windows Server 2008 R2 with Tomcat
7.0) on the same port (8009).
Again, testing a similar setup locally works as expected. The
authenticated Windows user name is passed to Tomcat.
How did you set up the s2wweb virtual directory?
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
-
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: Archive or package install
Hi Christopher, On 18.06.21 20:54, Christopher Schultz wrote: >> I would only stick to the distro-provided packages, if it is a small >> (in other words not that important) application running in Tomcat. Just >> for reference: With Ubuntu 18.04, you would end up >> with 9.0.16 vs. 9.0.48 (Tomcat project) or 8.5.39 vs. 8.5.68 (Tomcat >> project), which is about 2 years old software. > The above statement is *very* misleading. > > To understand why it's misleading, you have to understand the Debian "way" of > package-management. Ubuntu is Debian-derived and, although they have their > own package repositories, etc., they do > inherit from upstream and do make some changes on their own separate from > upstream. Thanks for picking that up, I was not clear enough by just referencing the security back ports in one sentence. It is right, that those distro packages get updates. My main point is, that due to the update policy of Ubuntu (and Debian as well), not all changes and updates will get into the distro packages. This might be an issue, especially if IT organisation stick to a specific distros version for a long time. This is not an issue with the distro policy or updates (never wanted to blame anyone from the Debian or Ubuntu team for that), but with the update policies of the running org. I was focusing on *Ubuntu 18.04* (which was mentioned by Onno), for that change log [1] mentions Wed, 11 Sep 2019 as last update. > All that junk at the end (-4~bpo9+1_all) indicates the various updates that > have been applied after the original 9.0.16. If you read the changelog[1] for > Buster, you'll see that it was last > updated as recently as 2021-04-12 to apply fixes for CVE-2021-25122 and > CVE-2021-25329 (thanks, Emmanuel!). In fact, in Buster, you are getting > 9.0.31. I'll bet if you look at the Ubuntu > changelog for your package, you'll find something similar. You are right, if you manage your base system and keep it updated to recent version (not my experience though), this will be fine. However if you stick as long as possible to a distros version (there is already a new Ubuntu LTS out for over a year, some time to update), you will have a gap to more recent Tomcat versions. Comparing Ubuntu 18.04 Tomcat versions to current Ubuntu or Debian versions, is not what was asked by the Onno. My experience is that some organisations try to stay on a specific distro version as long as possible. > If you are getting 9.0.16 from your Ubuntu repository, I think you may be > getting "left behind" by something. The current Ubuntu package should > actually be a base version of 9.0.43. Older > versions of Ubuntu have older base Tomcat versions. Again current vs. Ubuntu 18.04 is a different story. My apologies, I should have been clearer in my first post. [1] https://changelogs.ubuntu.com/changelogs/pool/universe/t/tomcat9/tomcat9_9.0.16-3ubuntu0.18.04.1/changelog regards, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Archive or package install
Hi Onno, On 18.06.21 07:07, Sugar Moose wrote: > I am using Ansible role robertdebock.tomcat to install Tomcat. This role uses > archives from the Tomcat site to install Tomcat. I have always thought that > this is a fine approach but the customer has pointed out that a package > install is preferred because it makes installing security updates easier. > This customer uses Ubuntu 18.04 and the position of the InfraOps engineers is > that installing Tomcat from the official Ubuntu repository is always > preferred. Installing Tomcat directly from the archives is easy and straight forward, in my opinion it should be perfectly fine using upstream as source (you should at least verify the download). Especially, if Tomcat plays a major role of the system (i.e. running some business critical applications), I would always stick to the version from Tomcat archives. You will end up with a more recent version of Tomcat, as it is actively developed, those versions will contain all security fixes (directly from the team and without possible backporting of security fixes). If you use CATALINA_HOME and CATALINA_BASE variables you can easily switch between different Tomcat versions, making it very easy to manage updates and possible necessary rollbacks. I would only stick to the distro-provided packages, if it is a small (in other words not that important) application running in Tomcat. Just for reference: With Ubuntu 18.04, you would end up with 9.0.16 vs. 9.0.48 (Tomcat project) or 8.5.39 vs. 8.5.68 (Tomcat project), which is about 2 years old software. For any errors you might get on distro packages, first hint would most likely be to update to a recent Tomcat version. Even if security fixed are backported by the distro, you would end up with versions missing a lot of fixes and improvements. > I don't know how exactly using apt packages makes life a lot easier when it > comes to security updates. I think it depends. If Ansible manages the version > it looks more or less the same to me. The Ansible role would have an var for > example tomcat_version and the value would determine the what version is on > the system. Updating Tomcat using Ansible would be same proces: update > tomcat_version var and provision the node. When Ansible is not managing the > version but is used for example only for the initial install using Ansible > package module it becomes a bit of a puzzle to figure out how this would > work. And also would have some drawbacks. Ansible is good at configuration > management and orchestration for example. Apt not really. Yes, Ansible is much more flexible for managing the configuration and deployment-parts. You will need something for that task, even if you use the distro-provided packages. > What is the position / what are the thoughts on this in the Tomcat community? > On the Tomcat website I could find no information on package install. I don't > think a recommended installation approach is mentioned there. In short: If your application in Tomcat is important, use the Tomcat archive up to date versions, if not distro packages might be sufficient. This might be challenging, if Tomcat is managed by the infrastructure team (from my experience, there is always a trend towards the distro packages, sometimes with the argument support by the distro). It might help, if managing the Tomcat can be done by the applications support/devops team (however, that might depend on the organisation constraints). hth, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: apache-tomcat-8.5.59 too many open files on Linux 8
Addendum : Maybe to debug this more efficiently, you could look at this issue from the opposite side : Earlier in the thread of messages, you said this : 1. Did you upgrade anything recently (like Java VM)? [YJ] To support Linux 8, only Postgres was upgraded from version 9.3 to 9.6. Maybe when you did this, you also changed the driver which tomcat is using to communicate with Postgresql. And maybe the problem lies in that driver. I mean that the driver is the piece of code which creates connections (using sockets) with Postgresql. And usually, that works and you have a number of ESTABLISHED connections (which are visible in the netstat output). But what if, occasionally, the connection doesn't work, and the driver is not very clean in handling this failing socket ? Or maybe the issue is in the code which uses these connections ? Have a look at this : https://stackoverflow.com/questions/2225221/closing-database-connections-in-java/2225275#2225275 On 26.05.2021 11:12, André Warnier (tomcat/perl) wrote: Maybe I am missing something, but at first sight it looks like lsof, inside the container, can also not get more information about these "sock" things. I am running out of ideas. If you search in Google for precisely this : lsof "sock" and "protocol : TCP" there are a lot of links which discuss similar issues, and this over many years. (So it is not either a unique or a recent issue). They all seem to boil down to this : some *application* is opening sockets, but then not really using them (and not closing them). In your case, that probably means one of the webapps running under tomcat. It seems quite unlikely that this would be tomcat itself, because if that was the case, this tomcat users list would probably be swamped with requests such as yours; which it isn't. It is worth noting also, that among all these messages found in Google, I have not so far seen a single one which provides another explanation for those "sock" things. In your case, the problem is going to be in finding out *which* webapp does that, unless there are not many, and you can turn them off one-by-one selectively. (The difficulty is in part due to the fact that, to the OS, the whole of the JVM, tomcat and all the webapps look like one single process; and to lsof also). Maybe there is some type of logging available in tomcat, that would help finding out which application is creating sockets, and then never using or destroying them. But my personal competences do not run that far, so maybe someone else can help you here. On 26.05.2021 00:03, Yeggy Javadi wrote: Hi, Below is the nsenter output: # ps -ef | grep tomcat root 165217 1 1 10:22 ? 00:05:33 /usr/local/jre/bin/java -Djava.util.logging.config.file=/usr/local/apache-tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -d64 -server -Xms1800m -Xmx8192m -XX:MaxMetaspaceSize=1800m -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Dignore.endorsed.dirs= -classpath /usr/local/apache-tomcat/bin/bootstrap.jar:/usr/local/apache-tomcat/bin/tomcat-juli.jar -Dcatalina.base=/usr/local/apache-tomcat -Dcatalina.home=/usr/local/apache-tomcat -Djava.io.tmpdir=/usr/local/apache-tomcat/temp org.apache.catalina.startup.Bootstrap start root 167329 167268 0 18:00 pts/1 00:00:00 grep --color=auto tomcat # nsenter -t 165217 --net lsof -n -p 165217 |less COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME java 165217 root cwd DIR 8,2 4096 157664 /usr/local/freestor/bin java 165217 root rtd DIR 8,3 4096 2 / java 165217 root txt REG 8,2 8712 8913 /usr/local/jdk/jre1.8.0_271/bin/java java 165217 root mem REG 8,2 113371 160881 /usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/hibernate-jpa-2.1-api-1.0.0.Final.jar java 165217 root mem REG 8,2 147874 160802 /usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/activemq-protobuf-1.1.jar java 165217 root mem REG 8,2 391515 160836 /usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/lucene-queryparser-4.10.4.jar java 165217 root mem REG 8,2 868615 160813 /usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-context-3.2.17.RELEASE.jar java 165217 root mem REG 8,2 9711 160792 /usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/slf4j-log4j12-1.6.6.jar java 165217 root mem REG 8,2 196573 160819 /usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-expression-3.2.17.RELEASE.jar java 165217 root mem REG 8,2 97173 160843 /usr/local/a
Re: apache-tomcat-8.5.59 too many open files on Linux 8
Maybe I am missing something, but at first sight it looks like lsof, inside the container, can also not get more information about these "sock" things. I am running out of ideas. If you search in Google for precisely this : lsof "sock" and "protocol : TCP" there are a lot of links which discuss similar issues, and this over many years. (So it is not either a unique or a recent issue). They all seem to boil down to this : some *application* is opening sockets, but then not really using them (and not closing them). In your case, that probably means one of the webapps running under tomcat. It seems quite unlikely that this would be tomcat itself, because if that was the case, this tomcat users list would probably be swamped with requests such as yours; which it isn't. It is worth noting also, that among all these messages found in Google, I have not so far seen a single one which provides another explanation for those "sock" things. In your case, the problem is going to be in finding out *which* webapp does that, unless there are not many, and you can turn them off one-by-one selectively. (The difficulty is in part due to the fact that, to the OS, the whole of the JVM, tomcat and all the webapps look like one single process; and to lsof also). Maybe there is some type of logging available in tomcat, that would help finding out which application is creating sockets, and then never using or destroying them. But my personal competences do not run that far, so maybe someone else can help you here. On 26.05.2021 00:03, Yeggy Javadi wrote: Hi, Below is the nsenter output: # ps -ef | grep tomcat root 165217 1 1 10:22 ?00:05:33 /usr/local/jre/bin/java -Djava.util.logging.config.file=/usr/local/apache-tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -d64 -server -Xms1800m -Xmx8192m -XX:MaxMetaspaceSize=1800m -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Dignore.endorsed.dirs= -classpath /usr/local/apache-tomcat/bin/bootstrap.jar:/usr/local/apache-tomcat/bin/tomcat-juli.jar -Dcatalina.base=/usr/local/apache-tomcat -Dcatalina.home=/usr/local/apache-tomcat -Djava.io.tmpdir=/usr/local/apache-tomcat/temp org.apache.catalina.startup.Bootstrap start root 167329 167268 0 18:00 pts/100:00:00 grep --color=auto tomcat # nsenter -t 165217 --net lsof -n -p 165217 |less COMMANDPID USER FD TYPE DEVICE SIZE/OFF NODE NAME java165217 root cwd DIR8,2 4096 157664 /usr/local/freestor/bin java165217 root rtd DIR8,3 40962 / java165217 root txt REG8,2 8712 8913 /usr/local/jdk/jre1.8.0_271/bin/java java165217 root mem REG8,2 113371 160881 /usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/hibernate-jpa-2.1-api-1.0.0.Final.jar java165217 root mem REG8,2 147874 160802 /usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/activemq-protobuf-1.1.jar java165217 root mem REG8,2 391515 160836 /usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/lucene-queryparser-4.10.4.jar java165217 root mem REG8,2 868615 160813 /usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-context-3.2.17.RELEASE.jar java165217 root mem REG8,2 9711 160792 /usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/slf4j-log4j12-1.6.6.jar java165217 root mem REG8,2 196573 160819 /usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-expression-3.2.17.RELEASE.jar java165217 root mem REG8,297173 160843 /usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/lucene-misc-4.10.4.jar java165217 root mem REG8,210074 160872 /usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/batik-ext-1.11.jar java165217 root mem REG8,262983 160861 /usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/activation-1.1.jar java165217 root mem REG8,2 371668 160812 /usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-security-core-3.2.9.RELEASE.jar java165217 root mem REG8,2 645914 160754 /usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/hibernate-entitymanager-4.3.5.Final.jar java165217 root mem REG8,2 427030 160753 /usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/hibernate-envers-4.3.5.Final.jar java165217 root mem REG8,2 256468 160829 /usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/barcode4j-2.0.jar java16521
Re: apache-tomcat-8.5.59 too many open files on Linux 8
Hi. The point is to try to figure out what these thousands of apparently "TCPv6" sockets belonging to the tomcat process actually are, so that we can maybe begin to look at where they may be coming from. The trouble is, the lsof output so far did not really tell us what these "sock" things might be. But there may be a clue here : https://serverfault.com/questions/1000338/in-lsof-output-what-are-those-sock-lines (about when things run in a container). Is that your case ? And if so, could you run the lsof command in the container, as they suggest ? And the point of forcing a tomcat/JVM GC was this : When you restart tomcat (actually the JVM which runs tomcat), the OS will clean up *all* the file descriptors belonging to that process, including the "legitimate" ones shown by netstat, and the "unknown" ones shown in addition by lsof. Doing a GC, without stopping the JVM, would clean up *only* such sockets/fd that are held by objects which are discarded, but still sit on the heap awaiting a GC to really destroy them. If your heap is very large, it may otherwise take a long while before such a GC happens, and such sockets could accumulate. One way to trigger a GC is through JMX, but it takes a bit of additional setup to make that work. That's why I was asking if you had some method to do that. (see : https://code.google.com/archive/p/jmxsh/) But let's look at the lsof part first. On 24.05.2021 16:09, Yeggy Javadi wrote: Hi, I restarted tomcat so PID has changed to 143152; I do not know how to trigger tomcat GC, I just restart it to reset the lsof to 0. Please see outputs below: # ps -ef | grep tomcat root 143152 1 0 May22 ?00:26:44 /usr/local/jre/bin/java -Djava.util.logging.config.file=/usr/local/apache-tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -d64 -server -Xms1800m -Xmx8192m -XX:MaxMetaspaceSize=1800m -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Dignore.endorsed.dirs= -classpath /usr/local/apache-tomcat/bin/bootstrap.jar:/usr/local/apache-tomcat/bin/tomcat-juli.jar -Dcatalina.base=/usr/local/apache-tomcat -Dcatalina.home=/usr/local/apache-tomcat -Djava.io.tmpdir=/usr/local/apache-tomcat/temp org.apache.catalina.startup.Bootstrap start root 153962 153912 0 10:00 pts/100:00:00 grep --color=auto tomcat # lsof -p 143152 | wc -l 41043 # lsof -p 143152 | grep "protocol: TCPv6"| wc -l 40487 # netstat -p -a -n --inet6 | grep 143152 tcp6 0 0 :::8443 :::*LISTEN 143152/java tcp6 0 0 :::443 :::*LISTEN 143152/java tcp6 0 0 127.0.0.1:8005 :::*LISTEN 143152/java tcp6 0 0 :::1099 :::*LISTEN 143152/java tcp6 0 0 :::80 :::*LISTEN 143152/java tcp6 0 0 :::36081:::*LISTEN 143152/java tcp6 0 0 10.4.3.55:60736 10.4.3.55:9300 ESTABLISHED 143152/java tcp6 0 0 10.4.3.55:60732 10.4.3.55:9300 ESTABLISHED 143152/java tcp6 0 0 10.4.3.55:60728 10.4.3.55:9300 ESTABLISHED 143152/java tcp6 0 0 10.4.3.55:8010.197.255.10:55446 ESTABLISHED 143152/java tcp6 1 0 10.4.3.55:55958 10.4.3.55:11576 CLOSE_WAIT 143152/java tcp6 0 0 10.4.3.55:53682 172.22.21.48:443ESTABLISHED 143152/java tcp6 0 0 127.0.0.1:48622 127.0.0.1:5432 ESTABLISHED 143152/java tcp6 0 0 10.4.3.55:60748 10.4.3.55:9300 ESTABLISHED 143152/java tcp6 1 0 10.4.3.55:55956 10.4.3.55:11576 CLOSE_WAIT 143152/java tcp6 0 0 10.4.3.55:40574 172.22.21.47:443ESTABLISHED 143152/java tcp6 0 0 127.0.0.1:48620 127.0.0.1:5432 ESTABLISHED 143152/java tcp6 0 0 10.4.3.55:53782 172.22.21.48:443ESTABLISHED 143152/java tcp6 0 1 10.4.3.55:49808 10.12.3.78:443 SYN_SENT 143152/java tcp6 0 0 10.4.3.55:60730 10.4.3.55:9300 ESTABLISHED 143152/java tcp6 0 0 10.4.3.55:60750 10.4.3.55:9300 ESTABLISHED 143152/java tcp6 0 0 10.4.3.55:60742 10.4.3.55:9300 ESTABLISHED 143152/java tcp6 0 0 10.4.3.55:60746 10.4.3.55:9300 ESTABLISHED 143152/java tcp6 0 0 127.0.0.1:48624 127.0.0.1:5432 ESTABLISHED 143152/java tcp6 0 0 10.4.3.55:60734 10.4.3.55:9300 ESTABLISHED 143152/java tcp6
Re: apache-tomcat-8.5.59 too many open files on Linux 8
Hi. I have no idea what lines like this are : java130244 root 78u sock0,9 0t0 12154374 protocol: TCPv6 There are obviously too many of them, for them to match with the sockets listed by netstat. The ones which in the lsof output, have "TYPE" set to "IPv6" seem to correspond to the ones marked as "LISTEN" in the netstat output. But the ones with TYPE="sock" and NAME="protocol: TCPv6" are a mystery to me. Could you redo a netstat as follows : # netstat -p -a -n --inet6 | grep 130244 and can you also try this form of lsof : # lsof -a -p 130244 -T s -i6 And finally (after copying the result of the above) : do you know how to trigger a GC (Garbage Collection) in your tomcat JVM ? (the point is to see if when a GC happens, these things disappear). On 22.05.2021 18:03, Yeggy Javadi wrote: Here it is: # netstat -p -a --tcp | grep 130244 tcp6 0 0 [::]:pcsync-https [::]:* LISTEN 130244/java tcp6 0 0 [::]:https [::]:* LISTEN 130244/java tcp6 0 0 [::]:37537 [::]:* LISTEN 130244/java tcp6 0 0 localhost.localdoma:mxi [::]:* LISTEN 130244/java tcp6 0 0 [::]:8009 [::]:* LISTEN 130244/java tcp6 0 0 [::]:rmiregistry[::]:* LISTEN 130244/java tcp6 0 0 [::]:http [::]:* LISTEN 130244/java tcp6 86 0 Yeggy-F8-FMSVA:39680172.22.22.192:https CLOSE_WAIT 130244/java tcp6 0 1 Yeggy-F8-FMSVA:5361810.12.3.78:httpsSYN_SENT 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54772Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 localhost.localdo:42664 localhost.loca:postgres ESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54782Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54766Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 localhost.localdo:42662 localhost.loca:postgres ESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54778Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54788Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54770Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54790Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54776Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54786Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54780Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 localhost.localdo:45736 localhost.loca:postgres ESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54768Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54784Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 localhost.localdo:42660 localhost.loca:postgres ESTABLISHED 130244/java tcp6 0 1 Yeggy-F8-FMSVA:4292210.12.3.77:httpsSYN_SENT 130244/java tcp6 0 0 Yeggy-F8-FMSVA:35794172.22.22.192:https ESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54774Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 localhost.localdo:45734 localhost.loca:postgres ESTABLISHED 130244/java tcp6 0 0 localhost.localdo:41016 localhost.localdo:vrace ESTABLISHED 130244/java # lsof -p 130244 COMMANDPID USER FD TYPE DEVICE SIZE/OFF NODE NAME java130244 root cwd DIR8,2 4096 157664 /usr/local/freestor/bin java130244 root rtd DIR8,3 40962 / java130244 root txt REG8,2 8712 8913 /usr/local/jdk/jre1.8.0_271/bin/java java130244 root mem REG8,2 498864 9007 /usr/local/jdk/jre1.8.0_271/lib/amd64/libfontmanager.so java130244 root mem REG8,239176 9006 /usr/local/jdk/jre1.8.0_271/lib/amd64/libawt_headless.so java130244 root mem REG8,2 759184 8996 /usr/local/jdk/jre1.8.0_271/lib/amd64/libawt.so java130244 root mem REG8,2 3559360 9139 /usr/local/jdk/jre1.8.0_271/lib/resources.jar java130244 root mem REG8,299680 133076 /usr/lib64/libgcc_s-8-20191121.so.1 java130244 root mem REG8,2 3135658 9133 /usr/local/jdk/jre1.8.0_271/lib/charsets.jar java130244 root mem REG8,2 283368 8980 /usr/local/jdk/jre1.8.0_271/lib/amd64/libsunec.so java130244 root mem REG
Re: apache-tomcat-8.5.59 too many open files on Linux 8
Mmm. Nothing very special in that netstat output. The sockets seen there look quite normal for tomcat, and there are not a lot. What about the IPv4 sockets ? (remove the -6 in your netstat command) Looks like lsof is counting things which are not IPv6 TCP sockets belonging to the tomcat JVM process. Where is the difference between the lsof count (19948) and the netstat count (25) ? (genuine question, I'm puzzled too) Can you give an example of the "lsof -p 130244" output lines ? (not all 19948 please, but enough to see some variety) On 21.05.2021 16:11, Yeggy Javadi wrote: Hi, Here its is: # lsof -p 130244 | grep "protocol: TCPv6"| wc -l 19948 # netstat -p -a -6 --tcp | grep 130244 tcp6 0 0 [::]:pcsync-https [::]:* LISTEN 130244/java tcp6 0 0 [::]:https [::]:* LISTEN 130244/java tcp6 0 0 [::]:37537 [::]:* LISTEN 130244/java tcp6 0 0 localhost.localdoma:mxi [::]:* LISTEN 130244/java tcp6 0 0 [::]:8009 [::]:* LISTEN 130244/java tcp6 0 0 [::]:rmiregistry[::]:* LISTEN 130244/java tcp6 0 0 [::]:http [::]:* LISTEN 130244/java tcp6 86 0 Yeggy-F8-FMSVA:39680172.22.22.192:https CLOSE_WAIT 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54772Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 localhost.localdo:42664 localhost.loca:postgres ESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54782Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54766Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 localhost.localdo:42662 localhost.loca:postgres ESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54778Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 localhost.localdo:46966 localhost.localdo:11753 ESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54788Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54770Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:http 10.197.255.10:64799 ESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54790Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54776Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54786Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54780Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 localhost.localdo:45736 localhost.loca:postgres ESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54768Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54784Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 localhost.localdo:42660 localhost.loca:postgres ESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:54774Yeggy-F8-FMSVA:vraceESTABLISHED 130244/java tcp6 0 0 localhost.localdo:45734 localhost.loca:postgres ESTABLISHED 130244/java tcp6 0 0 Yeggy-F8-FMSVA:http 10.197.255.10:64798 ESTABLISHED 130244/java tcp6 0 0 localhost.localdo:41016 localhost.localdo:vrace ESTABLISHED 130244/java Thanks -Original Message- From: Noelette Stout Sent: Friday, May 21, 2021 8:28 AM To: Tomcat Users List Subject: Re: apache-tomcat-8.5.59 too many open files on Linux 8 ss has all the same options as netstat On Fri, May 21, 2021 at 3:51 AM André Warnier (tomcat/perl) wrote: Soyrry to top-post, but it's getting cluttered down there.. The next thing that you may want to do : > netstat -p -a -6 --tcp That is an alternative list of sockets, which also shows the "tcp state" of the sockets. To get only the ones of the tomcat JVM PID, filter with grep based of the last column. The type of thing you are looking for is the column which should show "LISTEN", or "ESTABLISHED" or "CLOSE_WAIT" etc.. The options above : -p : show PID and program -a : show all sockets states -6 : only inet v6 --tcp : only TCP sockets "netstat" may not be on your system by default, and you may need to install it. An alternative is "ss", but I don't know the options. On 21.05.2021 02:14, Yeggy Javadi wrote: Hi, Yes; that is what I get and as you can see among 8028 open files, 7474 are for TCPv6 sockets: java130244 root 7805u sock0,9 0t0 12294251 protocol: TCPv6 # ps -ef | grep tomcat root 130244 1 1 11:01 ?00:06:20 /usr/local/jre/bin/java -Djava.util.logging.config.file=/usr/local/apache-tomcat/conf/logging. properties -Djava.util.logging.manager=org.apac
Re: apache-tomcat-8.5.59 too many open files on Linux 8
Soyrry to top-post, but it's getting cluttered down there.. The next thing that you may want to do : > netstat -p -a -6 --tcp That is an alternative list of sockets, which also shows the "tcp state" of the sockets. To get only the ones of the tomcat JVM PID, filter with grep based of the last column. The type of thing you are looking for is the column which should show "LISTEN", or "ESTABLISHED" or "CLOSE_WAIT" etc.. The options above : -p : show PID and program -a : show all sockets states -6 : only inet v6 --tcp : only TCP sockets "netstat" may not be on your system by default, and you may need to install it. An alternative is "ss", but I don't know the options. On 21.05.2021 02:14, Yeggy Javadi wrote: Hi, Yes; that is what I get and as you can see among 8028 open files, 7474 are for TCPv6 sockets: java130244 root 7805u sock 0,9 0t0 12294251 protocol: TCPv6 # ps -ef | grep tomcat root 130244 1 1 11:01 ?00:06:20 /usr/local/jre/bin/java -Djava.util.logging.config.file=/usr/local/apache-tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -d64 -server -Xms1800m -Xmx8192m -XX:MaxMetaspaceSize=1800m -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Dignore.endorsed.dirs= -classpath /usr/local/apache-tomcat/bin/bootstrap.jar:/usr/local/apache-tomcat/bin/tomcat-juli.jar -Dcatalina.base=/usr/local/apache-tomcat -Dcatalina.home=/usr/local/apache-tomcat -Djava.io.tmpdir=/usr/local/apache-tomcat/temp org.apache.catalina.startup.Bootstrap start root 132566 132492 0 20:10 pts/100:00:00 grep --color=auto tomcat #lsof -p 130244 | wc -l 8028 #lsof -p 130244 | grep "protocol: TCPv6"| wc -l 7474 Thanks -Original Message- From: André Warnier (tomcat/perl) Sent: Thursday, May 20, 2021 4:19 PM To: users@tomcat.apache.org Subject: Re: apache-tomcat-8.5.59 too many open files on Linux 8 Hi. According to the list below, you have 2 java (JVM) processes running on your system. One (PID = 130244) is the JVM which runs tomcat. This is visible when you look at the whole command-line. The other (PID = 130516) runs ElasticSearch, which I believe is not relevant here. So you should run lsof with the "-p 130244" option, to show only the files opened by the tomcat JVM. To show the current Tomcat JVM PID, do e.g. : ps -ef | grep "apache-tomcat" (or anything else unique in that line) On 20.05.2021 21:00, Yeggy Javadi wrote: Hi Chris, Please indicate how to show lsof or netstat to *just the JVM* process. Below is the list of running processes on my server: UID PIDPPID C STIME TTY TIME CMD root 1 0 0 May07 ?00:00:14 /usr/lib/systemd/systemd --switched-root --system --deserialize 17 root 2 0 0 May07 ?00:00:00 [kthreadd] root 3 2 0 May07 ?00:00:00 [rcu_gp] root 4 2 0 May07 ?00:00:00 [rcu_par_gp] root 6 2 0 May07 ?00:00:00 [kworker/0:0H-kblockd] root 8 2 0 May07 ?00:00:00 [mm_percpu_wq] root 9 2 0 May07 ?00:00:00 [ksoftirqd/0] root 10 2 0 May07 ?00:02:18 [rcu_sched] root 11 2 0 May07 ?00:00:00 [migration/0] root 12 2 0 May07 ?00:00:00 [watchdog/0] root 13 2 0 May07 ?00:00:00 [cpuhp/0] root 14 2 0 May07 ?00:00:00 [cpuhp/1] root 15 2 0 May07 ?00:00:00 [watchdog/1] root 16 2 0 May07 ?00:00:00 [migration/1] root 17 2 0 May07 ?00:00:00 [ksoftirqd/1] root 19 2 0 May07 ?00:00:00 [kworker/1:0H-kblockd] root 20 2 0 May07 ?00:00:00 [cpuhp/2] root 21 2 0 May07 ?00:00:00 [watchdog/2] root 22 2 0 May07 ?00:00:00 [migration/2] root 23 2 0 May07 ?00:00:00 [ksoftirqd/2] root 25 2 0 May07 ?00:00:00 [kworker/2:0H-kblockd] root 26 2 0 May07 ?00:00:00 [cpuhp/3] root 27 2 0 May07 ?00:00:00 [watchdog/3] root 28 2 0 May07 ?00:00:00 [migration/3] root 29 2 0 May07 ?00:00:00 [ksoftirqd/3] root 31 2 0 May07 ?00:00:00 [kworker/3:0H-kblockd] root 32 2 0 May07 ?00:00:00 [cpuhp/4] root 33 2 0 May07 ?00:00:00 [watchdog/4] root 34 2 0 May07 ?00:00:00 [migration/4] root 35 2 0 May07 ?00:00:00 [ksoftirqd/4] root 37 2 0 May07 ?00:00:00 [kworker/4:0H-kblockd] ro
Re: apache-tomcat-8.5.59 too many open files on Linux 8
Hi. According to the list below, you have 2 java (JVM) processes running on your system. One (PID = 130244) is the JVM which runs tomcat. This is visible when you look at the whole command-line. The other (PID = 130516) runs ElasticSearch, which I believe is not relevant here. So you should run lsof with the "-p 130244" option, to show only the files opened by the tomcat JVM. To show the current Tomcat JVM PID, do e.g. : ps -ef | grep "apache-tomcat" (or anything else unique in that line) On 20.05.2021 21:00, Yeggy Javadi wrote: Hi Chris, Please indicate how to show lsof or netstat to *just the JVM* process. Below is the list of running processes on my server: UID PIDPPID C STIME TTY TIME CMD root 1 0 0 May07 ?00:00:14 /usr/lib/systemd/systemd --switched-root --system --deserialize 17 root 2 0 0 May07 ?00:00:00 [kthreadd] root 3 2 0 May07 ?00:00:00 [rcu_gp] root 4 2 0 May07 ?00:00:00 [rcu_par_gp] root 6 2 0 May07 ?00:00:00 [kworker/0:0H-kblockd] root 8 2 0 May07 ?00:00:00 [mm_percpu_wq] root 9 2 0 May07 ?00:00:00 [ksoftirqd/0] root 10 2 0 May07 ?00:02:18 [rcu_sched] root 11 2 0 May07 ?00:00:00 [migration/0] root 12 2 0 May07 ?00:00:00 [watchdog/0] root 13 2 0 May07 ?00:00:00 [cpuhp/0] root 14 2 0 May07 ?00:00:00 [cpuhp/1] root 15 2 0 May07 ?00:00:00 [watchdog/1] root 16 2 0 May07 ?00:00:00 [migration/1] root 17 2 0 May07 ?00:00:00 [ksoftirqd/1] root 19 2 0 May07 ?00:00:00 [kworker/1:0H-kblockd] root 20 2 0 May07 ?00:00:00 [cpuhp/2] root 21 2 0 May07 ?00:00:00 [watchdog/2] root 22 2 0 May07 ?00:00:00 [migration/2] root 23 2 0 May07 ?00:00:00 [ksoftirqd/2] root 25 2 0 May07 ?00:00:00 [kworker/2:0H-kblockd] root 26 2 0 May07 ?00:00:00 [cpuhp/3] root 27 2 0 May07 ?00:00:00 [watchdog/3] root 28 2 0 May07 ?00:00:00 [migration/3] root 29 2 0 May07 ?00:00:00 [ksoftirqd/3] root 31 2 0 May07 ?00:00:00 [kworker/3:0H-kblockd] root 32 2 0 May07 ?00:00:00 [cpuhp/4] root 33 2 0 May07 ?00:00:00 [watchdog/4] root 34 2 0 May07 ?00:00:00 [migration/4] root 35 2 0 May07 ?00:00:00 [ksoftirqd/4] root 37 2 0 May07 ?00:00:00 [kworker/4:0H-kblockd] root 38 2 0 May07 ?00:00:00 [cpuhp/5] root 39 2 0 May07 ?00:00:00 [watchdog/5] root 40 2 0 May07 ?00:00:00 [migration/5] root 41 2 0 May07 ?00:00:00 [ksoftirqd/5] root 43 2 0 May07 ?00:00:00 [kworker/5:0H-kblockd] root 44 2 0 May07 ?00:00:00 [cpuhp/6] root 45 2 0 May07 ?00:00:00 [watchdog/6] root 46 2 0 May07 ?00:00:00 [migration/6] root 47 2 0 May07 ?00:00:00 [ksoftirqd/6] root 49 2 0 May07 ?00:00:00 [kworker/6:0H-kblockd] root 50 2 0 May07 ?00:00:00 [cpuhp/7] root 51 2 0 May07 ?00:00:00 [watchdog/7] root 52 2 0 May07 ?00:00:00 [migration/7] root 53 2 0 May07 ?00:00:00 [ksoftirqd/7] root 55 2 0 May07 ?00:00:00 [kworker/7:0H-kblockd] root 57 2 0 May07 ?00:00:00 [kdevtmpfs] root 58 2 0 May07 ?00:00:00 [netns] root 59 2 0 May07 ?00:00:00 [kauditd] root 62 2 0 May07 ?00:00:00 [khungtaskd] root 63 2 0 May07 ?00:00:00 [oom_reaper] root 64 2 0 May07 ?00:00:00 [writeback] root 65 2 0 May07 ?00:00:00 [kcompactd0] root 66 2 0 May07 ?00:00:00 [ksmd] root 67 2 0 May07 ?00:00:02 [khugepaged] root 68 2 0 May07 ?00:00:00 [crypto] root 69 2 0 May07 ?00:00:00 [kintegrityd] root 70 2 0 May07 ?00:00:00 [kblockd] root 71 2 0 May07 ?00:00:00 [tpm_dev_wq] root 72 2 0 May07 ?00:00:00 [md] root 73 2 0 May07 ?00:00:00 [edac-poller] root 74 2 0 May07 ?00:00:00 [watchdogd] root 92 2 0 May07 ?00:00:00 [kswapd0] root 188 2 0 May07 ?00:0
Re: [OT] programming style or mental process ?
On 06.04.2021 20:06, gustavo.avitab...@unina.it wrote: To nitpick, in Spanish one would rather say "cafe frio". ... and, in Italian, "caffè freddo", but we Italians love coffee, and we have much phantasy, so try also: "granita di caffè", "caffè gelato", "caffè col ghiaccio", "il caffè s'è fatto freddo", ... Not so you'd think that Italians are the only ones with imagination when it comes to coffee, Spanish people also call this "granizado de cafe" (or "cafe granizado") or "cafe del tiempo". And that's only for the basic cold type, because there are many subtypes each with it's own name, with and without different types of liquor (flambé or not), short, medium, large or "americano" (== like water), real coffee or powder, decaffeinated or not, with or without (hot or cold) milk, in different types of recipients. And not that some people would think that this is now all totally [OT], I would remind everyone of the definite historical and cultural connections between Tomcat, Java, programming and coffee (and Jakarta). (And dutch people. Where are they in this discussion by the way ? (but they have only one type of coffee I think)). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What exactly does the AJP connector on 8009 do?
On 06.04.2021 00:45, James H. H. Lampert wrote: On 4/5/21 1:22 PM, Christopher Schultz wrote: If you are not running a reverse-proxy in front of Tomcat, then it does absolutely nothing for you. If you *are* running a reverse-proxy in front of Tomcat, then it *may* do something for you, depending upon what software you are using and what its configuration is. Thanks. Hmm. We have *something* on one of our cloud servers, that has Tomcat sitting behind httpd (on the same box), and we have load balancing (through a couple of AWS Beanstalks) on our cloud-based product, but I don't know if the AJP port is involved in any of that. I don't know about AWS Beanstalks, but for Apache httpd, there are some tell-tale configuration directives in the Apache httpd configuration files, which - if present - will tell you if Apache httpd is communicating with the back-end tomcat using the AJP protocol (and hence tomcat's AJP Connector). Look for either of : - ProxyPass instructions mentioning "AJP:" - SetHandler jakarta-servlet - JkMount (case does generally not matter) (Note that under Linux(es), your Apache httpd config files may be spread in small chunks all over the place, generally in locations such as "/etc/apache2/*" or "/etc/httpd/*") (*) Relevant documentation is available here : 1) http://tomcat.apache.org/connectors-doc/ 2) http://tomcat.apache.org/connectors-doc/reference/apache.html 3) http://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass 4) (more complicated cases) http://httpd.apache.org/docs/2.4/mod/mod_rewrite.html#rewriterule Also, if Apache httpd uses AJP to communicate with tomcat, then either one of these Apache httpd add-on modules will be loaded and configured : - mod_jk - mod_proxy_ajp To find out which modules are loaded by Apache httpd, use the following command : # apache2ctl -M (Note that the mere fact that a module is loaded, does not necessarily mean that it is being *used*; but if neither of them is loaded, then you can be pretty sure that Apache httpd is NOT using AJP) Shortcut : - comment-out the AJP Connector in the tomcat configuration - restart tomcat - and wait for desperate support calls (*) This is not a critic : it is very flexible that way; it's just a bit more work to search for the right files. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] programming style or mental process ?
On 05.04.2021 14:37, Christopher Schultz wrote:
Or, more literarily, given that the syntax of most (all?) programming languages is based
on English (if, then, else, new, for, while, until, exit, continue, etc.), we (*) do
normally ask "is your coffee cold ?" and not "is cold your coffee ?".
On the other hand, in English, coffee which is not hot is called "cold coffee" but in e.g.
Spanish, it's "coffee cold".
To nitpick, in Spanish one would rather say "cafe frio".
But that's a bit beside the point since - as mentioned above - most currently fashionable
programming languages are based on English.
Nevertheless, just for the sake of it, and in some imaginary situation
in which the Java syntax would be based on Spanish, one would probably have
this :
si (nada == requerimiento.obtengaCodificaciónCarácteros()) entonces {
} sino {
}
as opposed to
si (requerimiento.obtengaCodificaciónCarácteros() == nada) entonces {
} sino {
}
.. which makes it even more striking that the first form deviates from the human language,
because "nothing" cannot really be equal to anything, and thus the first form should
always evaluate to false. (*)
(Which would also lead to more concise Java programs, because if you already know the
answer, then you don't even need to make the test in the first place.)
On the other hand, this provides an interesting insight into English-speaking people's
thought processes, for example as to the expression "nothing matches a good coffee in the
morning", which is undoubtedly evaluated as true by many, although logically it cannot be.
:-)
(*) actually, this appears to be false : in Java, (null == null) is true.
See here for an in-depth discussion :
https://stackoverflow.com/questions/2707322/what-is-null-in-java
P.S.
If anyone is interested about how it would be to write programs based on a Latin-inspired
programming language, I recommend this :
https://metacpan.org/pod/distribution/Lingua-Romana-Perligata/lib/Lingua/Romana/Perligata.pm
(in which language it would be very difficult to confuse "==" and "=")
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] programming style or mental process ?
On 05.04.2021 00:21, Zala Pierre GOUPIL wrote: In your case, with a function call, this wouldn't make a difference "if(request.getCharacterEncoding() = null)" would be illegal syntax as well, but "if(someObject = null)" is perfectly legal, but doesn't express the author's intent clearly: Is it a smart person who's taking a shortcut, or a newbie using the wrong operator? Let the seasoned programmer who's never made that same mistake throw the first stone. I think I never did that mistake. Or at least, I didn't realize it. J'ai jamais tué d'chats Ou alors y'a longtemps Ou bien j'ai oublié Ou ils sentaient pas bon (Jacques Brel - Ces gens-là) Couldn't resist. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] programming style or mental process ?
On 04.04.2021 12:57, Olaf Kock wrote:
Hi André
On 04.04.21 12:23, André Warnier (tomcat/perl) wrote:
if (null == request.getCharacterEncoding()) {
as opposed to
if (request.getCharacterEncoding() == null) {
So why do (some) people write it the other way ?
Is it purely a question of individual programming style ?
Is there some (temporary ?) fashion aspect involved ?
Do the people who write this either way really think in a different way ?
Or is there really something "technical" behind this, which makes one
or the other way be slightly more efficient (whether to compile, or
optimise, or run) ?
(*) excepting Yoda of course
I can't say I'm always writing Yoda style, but if I stretch my memory,
then the rationale behind this style of comparisons is to have a
constant on the left side, so that you get a compiler error in case
you're using = instead of ==.
I like that explanation, in the sense that it provides a programming rationale for using
the first form (and not only in Java), even if it feels intuitively un-natural.
So it's apparently not only fashion or Yoda fandom.
Thanks.
In your case, with a function call, this wouldn't make a difference
"if(request.getCharacterEncoding() = null)" would be illegal syntax as
well, but "if(someObject = null)" is perfectly legal, but doesn't
express the author's intent clearly: Is it a smart person who's taking a
shortcut, or a newbie using the wrong operator?
Let the seasoned programmer who's never made that same mistake throw the first
stone.
Of course, the style doesn't really help people new to the language, as
they first need to understand that this is something that they might
want to apply to their code. And today, with so many IDE warnings being
flagged while typing, it might be outdated, though it still clearly
expresses the intent to have a real comparison and not an assignment here.
And I agree with the other answer posted already: It makes a lot more
sense in C++ with all the implicit boolean conversions and habits of
outsmarting the code's maintainers with clever expressions.
+1 to that too.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
[OT] programming style or mental process ?
Hi.
I have a question which may be totally off-topic for this list, but this has been puzzling
me for a while and I figure that someone here may be able to provide some clue as to the
answer, or at least some interesting ponts of view.
In various places (including on this list), I have seen multiple occurrences of a certain
way to write a test, namely :
if (null == request.getCharacterEncoding()) {
as opposed to
if (request.getCharacterEncoding() == null) {
Granted, the two are equivalent in the end.
But it would seem to me, maybe naively, that the second form better corresponds to some
"semantic logic", by which one wants to know if a certain a-priori unknown piece of data
(here the value obtained by retrieving the character encoding of the current request) is
defined (not null) or not (null).
Said another way : we don't want to know if "null" is equal to anything; we want to know
if request.getCharacterEncoding() is null or not.
Or in yet another way : the focus (or the "subject" of the test) here is on
"request.getCharacterEncoding()" (which we don't know), and not on "null" (which we know
already).
Or, more literarily, given that the syntax of most (all?) programming languages is based
on English (if, then, else, new, for, while, until, exit, continue, etc.), we (*) do
normally ask "is your coffee cold ?" and not "is cold your coffee ?".
So why do (some) people write it the other way ?
Is it purely a question of individual programming style ?
Is there some (temporary ?) fashion aspect involved ?
Do the people who write this either way really think in a different way ?
Or is there really something "technical" behind this, which makes one or the other way be
slightly more efficient (whether to compile, or optimise, or run) ?
(*) excepting Yoda of course
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Working with SAML
On 17.03.2021 17:49, Christopher Schultz wrote: André, On 3/16/21 18:21, André Warnier (tomcat/perl) wrote: Alternatively, see this : https://wiki.shibboleth.net/confluence/display/SP3/JavaHowTo Thanks for mentioning this. I looked at Shibboleth. Their web site says "version 3 is deprecated" and "version 4 is undocumented". We've been using versions 2 and 3 without problems. I don't know what version 4 brings, that is not in the others but nevertheless helpful. We've set up one (our own) IdP (the SAML "identity provider", where the clients really login), and several SP (Service Provider), which interact with our own IdP or with other people's IdP's (of various brands/makes/types). It's all a bit of work to set up, but once set up it hasn't given us any more hassle. The documentation for versions 2 and 3 is very extensive, and quite complex, which I believe is kind of unavoidable considering that SAML itself is one of these things designed by a committee. (We also have our own summarised installation and setup documentation, so if you want any tips, just ask) :( That's not exactly encouraging. Thanks, -chris On 16.03.2021 21:18, Christopher Schultz wrote: Robert, On 3/16/21 14:33, Robert Turner wrote: Chris, I'm not sure if it will do what you want, but when sourcing Java-based SAML libraries for our use as an SP, I too found that most of the libraries were much larger and more complicated that I thought necessary. We went with the (limited but simple to use) OneLogin libraries for our use case. It doesn't do everything by any means, but was considerably smaller and simpler than most packages out there. I did see the OneLogin library. You mean this one, right? https://github.com/onelogin/java-saml Is there anything tied to any particular service for that? Or do they simply give-away their library for use anywhere? Thanks, -chris On Tue, Mar 16, 2021 at 1:55 PM Christopher Schultz < ch...@christopherschultz.net> wrote: All, I've got a system which is accepting one-legged, signed SAML responses from trusted third parties and going all the right things. It's working great. It's time to look at doing the opposite: assembling our own SAML responses, signing them, and sending them to another party. I'm sure I could manually create a DOM document with all the right namespaces, add the various values that I need, and then use XML DSIG using the bits and pieces that are provided by Java directly, but there's got to be a nice compact library that doesn't require me to download the entire internet in order to use in my product. Any recommendations? Thanks, -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 - 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: [OT] Working with SAML
Alternatively, see this : https://wiki.shibboleth.net/confluence/display/SP3/JavaHowTo On 16.03.2021 21:18, Christopher Schultz wrote: Robert, On 3/16/21 14:33, Robert Turner wrote: Chris, I'm not sure if it will do what you want, but when sourcing Java-based SAML libraries for our use as an SP, I too found that most of the libraries were much larger and more complicated that I thought necessary. We went with the (limited but simple to use) OneLogin libraries for our use case. It doesn't do everything by any means, but was considerably smaller and simpler than most packages out there. I did see the OneLogin library. You mean this one, right? https://github.com/onelogin/java-saml Is there anything tied to any particular service for that? Or do they simply give-away their library for use anywhere? Thanks, -chris On Tue, Mar 16, 2021 at 1:55 PM Christopher Schultz < ch...@christopherschultz.net> wrote: All, I've got a system which is accepting one-legged, signed SAML responses from trusted third parties and going all the right things. It's working great. It's time to look at doing the opposite: assembling our own SAML responses, signing them, and sending them to another party. I'm sure I could manually create a DOM document with all the right namespaces, add the various values that I need, and then use XML DSIG using the bits and pieces that are provided by Java directly, but there's got to be a nice compact library that doesn't require me to download the entire internet in order to use in my product. Any recommendations? Thanks, -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: Run servlets on Nashorn written in server-side JavaScript
On 17.02.2021 14:59, Christopher Schultz wrote: Rony and Leo, On 2/17/21 02:58, Rony G. Flatscher (Apache) wrote: Hi Leo, why would you want to do that if you could do the same with Java? What is the motivation, the use case for you? How urgent is this (I may have something for both, Java EE and Jakarta EE, but need a little bit of time)? —-rony On 15.02.2021 07:29, leo wrote: Hi there I am trying to find out how to process servlets written in server-side JavaScript through Tomcat. I looked through the Tomcat FAQ and How-To but couldn't find anything. By googling I found a way to hook up Python through Jython's PyServlet class. I tried this and it works great. But I am looking for server-side JavaScript in Tomcat. I am aware of the JavaScript engine Nashorn. Is there a way to hook up Nashorn with a servlet class, so that Tomcat serves JavaScript servlets? Something like a "JavaScript Server Page" for Tomcat would be fine too. Many thanks for any pointers, Leo ps: I use Tomcat 8.5, but I could move to another Tomcat version for this. Weird; I never saw the OP on the list, only Rony's reply. Usually if you want to use server-side JavaScript, you use something like Node.js instead of a servlet container. Why not use Node? If you'd really like to use Tomcat, you will need to write a Servlet that establishes a JavaScript environment (e.g. Nashhorn), provides all the plumbing for the servlet-container provided resources (e.g. request, response, streams, session, etc.) as well as error-handling, etc. It's a big job. I'd be surprised is nobody had built something like this before. Or maybe everybody just uses Node.js. +1. On the face of it, it looks much simpler to set up a local Nodejs server, and proxy the corresponding requests from Tomcat to it. Perhaps have a look at this ? https://stackoverflow.com/questions/42057314/how-to-implement-an-application-proxy-in-java-on-tomcat Or use an Apache httpd front-end to filter requests and do the proxying to Nodejs and Tomcat. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat server not considering Mime Type - Request urgent help!!
Hi again. Sorry for the noise. The page which you quoted (https://www.geeksforgeeks.org/http-headers-content-disposition/), itself contains a formal reference to RFC 5987 (https://tools.ietf.org/html/rfc5987), which formally defines the extended "filename*" header parameter below. On 15.01.2021 11:48, André Warnier (tomcat/perl) wrote: On 14.01.2021 22:55, Christopher Schultz wrote: Content-Disposition: attachment; filename="[filename]"; filename*=utf-8''[filename in UTF-8 encoding] Hi Chris. Do you have any reference for the above ? (the "utf8''" part is new to me) - 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: Tomcat server not considering Mime Type - Request urgent help!!
On 14.01.2021 22:55, Christopher Schultz wrote: Content-Disposition: attachment; filename="[filename]"; filename*=utf-8''[filename in UTF-8 encoding] Hi Chris. Do you have any reference for the above ? (the "utf8''" part is new to me) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat SSO valve implementation
On 16.12.2020 19:39, Kevin Oxley wrote: We are trying to support SSO SAML 2.0 for user authentication in Tomcat (9.0.22). Can anybody provide a reference to a pre-integrated SAML SSO valve implementation that you've had a good experience with? searching Google for "SAML SP for servlet engine" gives a few links, among them this one : https://dzone.com/articles/saml-single-sign-on-with-tomcat-and-picketlink I haven't tried it myself. In my cases, I always use an Apache httpd front-end, which does the authentication prior to proxying to a back-end tomcat (with the Connector attribute ' tomcatAuthentication="false" '). In the front-end Apache2 httpd then, we use Shibboleth as the SAML SP side. That works perfectly. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Exit code 6 on shutting down Tomcat service
Hi. On 30.09.2020 14:40, Jakub Moravec wrote: Hello Tomcat team, we are having an issue that we were not able to resolve ourselves or using the existing documentation, so I'd like to ask you for help. Description: During Tomcat service shutdown (using command /bin/tomcat9.exe //SS//), we sometimes receive exit code 6. You may want to have a look at these : - https://cwiki.apache.org/confluence/display/TOMCAT/Windows#Windows-Q11 - http://tomcat.apache.org/tomcat-9.0-doc/windows-service-howto.html These pages do not explain why you get an exit code 6 from tomcat9.exe. But they explain what tomcat9.exe actually is, which may help for what follows (*) The documentation page http://tomcat.apache.org/tomcat-9.0-doc/windows-service-howto.html, at the end, lists some additional tomcat9.exe command-line parameters (the ones starting with "--Log") which may enable you to find out more details about the internal error that triggers this exit code. (e.g : --LogLevel "Debug")(and where to find that logfile) The mailing list archives, at https://markmail.org/list/org.apache.commons.users/ may also help finding the reason (in the search box, enter "daemon", or "daemon exit") (*) the tomcat9.exe program is actually a renamed copy of the Apache Commons Daemon "prunsrv" program, which the tomcat team adds to the tomcat-for-Windows package, to facilitate installing and running tomcat as a Windows service. It happens underministically (or at least we don't know the exact circumstances under which the error code is returned). We were not able to find any information about this exit code or any suggestions for fixes in the documentation. Environment: Tomcat: 9.0.33 OS: Windows 2016, Version: 10.0, Flavor: Data Center Thank you for your assistance! Jakub Moravec jakub.mora...@getmanta.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP2: memory filled up fast on increasing the connections to 1000/2000 (Embedded tomcat 9.0.38)
On 30.09.2020 07:42, Arshiya Shariff wrote: Hi Martin , Thank you for the response. With a payload of 200 bytes we were able to send 20K requests/sec with 200 users from Jmeter without any memory issue . On increasing the payload to 5Kb and the number of users to 1000 in Jmeter and sending 1000 requests per second , the heap of 20GB got filled in 2 minutes . How long does it typically take (at the beginning of the test) for tomcat to *process* one of these requests ? With 200 users the memory is cleared in the G1 mixed GC itself , but with 1000 users the memory is not cleared in the mixed GC , it takes full GCs of 7 to 10 seconds to clear the memory. These cases were executed with maxThreads 200 in tomcat , so we tried increasing the maxThreads from 200 to 1000, but still GC was struggling . When we tried with 10 instances of JMeter , each with 100 users , where each instance was started with a delay of 1 minute we were able to see 1000 connections created in tomcat without any memory issues. But when 1000 users are created using single instance of JMeter in 20 seconds , tomcat's memory is filling fast- 20GB in 2 minutes. We suspect that the burst of connections being opened has a problem . Please help us with the same . On analyzing the heap dump we see org.apache.tomcat.util.collections.SynchronizedStack occupying around 93% of 3GB live data ,the remaining 17GB is Garbage collected in the heap dump. Thanks and Regards Arshiya Shariff -Original Message- From: Martin Grigorov Sent: Monday, September 28, 2020 11:44 PM To: Tomcat Users List Subject: Re: HTTP2: memory filled up fast on increasing the connections to 1000/2000 (Embedded tomcat 9.0.38) Hi Arshiya, On Mon, Sep 28, 2020 at 7:59 PM Arshiya Shariff wrote: Hi All, With 200 threads(users) , ramp up duration of 2 seconds , loop count 80 and by sending 1000 http2 requests/sec from JMeter Client to an embedded tomcat application we did not observe any memory issue , but on sending 1000 http2 requests/sec with 2000 or 1000 users from JMeter , the application's heap space of 20 GB is occupied in 2 minutes and after 2 full GCs the memory clears and comes down to 4GB (expected) . I am not sure whether you follow the other discussions at users@. In another email thread we discuss load testing Tomcat HTTP2 and we are able to make around 12K reqs/s with another load testing tool - https://protect2.fireeye.com/v1/url?k=f8cfc13c-a66f0379-f8cf81a7-8692dc8284cb-2c0aae53194b790f=1=6a9c569d-7da1-4394-a9ac-bf72724992fa=https%3A%2F%2Fgithub.com%2Ftsenart%2Fvegeta For me JMeter itself failed with OOM when increasing the number of the virtual users above 2K. There are several improvements in Tomcat master and 9.0.x in the HTTP2 area. Some of the changes are not yet downported to 9.0.x. We still test them, trying to avoid introducing regressions in 9.0.x. Embedded tomcat Version:9.0.38 Max Threads : 200 The number of threads should be less if you do only CPU calculations without IO/network. If your app blocks on IO/network calls then you need more spare threads. With more threads there will be more context switches and less throughput. That's why there is no one golden rule that applies to all applications. 200 is a good default that works for most of the applications. But you need to test with different values to see which one gives the best performance for your scenaria. All other properties are the tomcat defaults. Why is tomcat not able to process many connections ? You can tell us by enabling -XX:+HeapDumpOnOutOfMemoryError and -XX:HeapDumpPath=. Once you have the .hprof file you can examine it with Eclipse Memory Analyzer tool and see what is leaking. I will try to reproduce this issue tomorrow with Vegeta. Why is the memory filled when the connections are increased, are there any parameters to tune connections ? Please let us know. Thanks and Regards Arshiya Shariff - 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: WebSocket connection silently drops
It turns out that I was premature in concluding connections were silently getting dropped. I left the client application running for another quarter hour after it stopped displaying message updates from the server. On shutting it down, the server immediately recorded that the client had just disconnected. This indicates that the WebSocket connection is not being silently dropped afterall, rather the client is becoming deaf to inbound messages after a few minutes. Exactly why this is is a mystery. But evidently it is a Tyrus rather than a Tomcat or network issue (they communicate across the internet, to answer your earlier question). Regards, Chris. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
WebSocket connection silently drops
Hi, I have a desktop application that, using the org.glassfish.tyrus WebSocket implementation, connects and talks with a parent web application running on Tomcat. All runs well for a while but, after data transfer falls quiet for a few minutes, the connection gets silently dropped (nothing in the logs). The ServerEndpoint onOpen() method sets the session to never timeout: session.setMaxIdleTimeout(0). But this hasn't had the desired effect. I've not (yet) implemented a game of ping pong to keep connections alive over long periods of time. Still, I'd like to know why connections consistently get dropped after just a matter of minutes, and whether this can be resolved with a simple configuration change. Web.xml is configured to keep sessions alive for 720 minutes, so the problem is not there. 720 WebSocket connections are handled by Tomcat port 8080, and as you can see this is set in server.xml to timeout after just 20 seconds. I haven't tried extending this for fear it may have undesirable side effects. Anyway, connections are dropping after several minutes, not 20 seconds. protocol="HTTP/1.1" connectionTimeout="2" redirectPort="8443" /> Any suggestions much appreciated. Regards, Chris. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Handling close_waits
Hi. On 17.08.2020 02:51, Norbert Elbanbuena wrote: Hi Paul, Yes these are some samples, I have about 300 of them getting stuck hourly tcp 761 0 192.168.1.50:58870 74.112.28.109:8011 CLOSE_WAIT tcp0 0 192.168.1.50:56938 192.168.1.50:61616 CLOSE_WAIT tcp0 0 192.168.1.50:56924 192.168.1.50:61616 CLOSE_WAIT tcp0 0 192.168.1.50:56910 192.168.1.50:61616 CLOSE_WAIT tcp0 0 192.168.1.50:56912 192.168.1.50:61616 CLOSE_WAIT tcp6 0 6240 192.168.1.50:44352.11.72.45:47123 CLOSE_WAIT tcp6 32 0 192.168.1.50:44334.209.104.242:13402CLOSE_WAIT tcp6 268 0 192.168.1.50:443108.162.244.28:40864CLOSE_WAIT tcp6 32 0 192.168.1.50:44335.167.185.49:10019 CLOSE_WAIT tcp6 32 0 192.168.1.50:44352.24.48.141:60660 CLOSE_WAIT tcp6 202 0 192.168.1.50:443199.189.191.86:51716CLOSE_WAIT tcp6 202 0 192.168.1.50:443199.189.191.86:1386 CLOSE_WAIT Try forcing a Java Garbage Collection in Tomcat, and check if these CLOSE_WAIT sockets are still there after that. If they are gone, you probably have a server application which leaves these sockets "dangling" and does not properly close them. Other people on this list may be able to provide a simpler way to trigger a GC, but I used a script with "jmxsh", like this : # gc_tomcat.jmxsh # force the target JVM to do a GC, from the jmxsh shell # invoke as : # java -jar jmxsh.jar gc_tomcat.jmxsh # # In the following command, replace the port number (-p) # by the port which has been specified in the parameter : # -Dcom.sun.management.jmxremote.port=x # of the target Java JVM startup line jmx_connect -h 127.0.0.1 -p (port) -U (userid) -P (password) jmx_invoke -m java.lang:type=Memory gc jmx_close for jmxsh, see : - https://github.com/davr/jmxsh - http://isbyr.com/use-jmxsh-jmx-cli-tool-to-troubleshoot-remote-jmx-connection/ Warm regards, Norbert -Original Message- From: Paul Carter-Brown Sent: Sunday, August 16, 2020 2:43 PM To: Tomcat Users List Subject: Re: Tomcat Handling close_waits Hi Norbert, The TCP socket states and timers are managed by the underlying OS and not by Tomcat. Can you paste a netstat -an result so I can see what you mean. Also, is the client using HTTP 1.1 with keep-alive or not? What kind of traffic is this? Paul On Sun, Aug 16, 2020 at 7:16 PM Norbert Elbanbuena wrote: I also noticed that while server receives the connection requests, we are seeing multiple requests from the same sources. Some same source requests (FIN-WAIT) are all in state while other same sources requests are in other state (some in FIN-WAIT or close_wait and some Established). Why are we seeing multiple requests from the same source at the same time? Doesn't each socket request exhaust a thread on the application? Warm regards, Norbert Elbanbuena -Original Message- From: Norbert Elbanbuena Sent: Sunday, August 16, 2020 11:35 AM To: Tomcat Users List Subject: Tomcat Handling close_waits Hi, We are experiencing a flood of close_waits in our server. Interestingly, all of the sessions stuck in close_waits are sourced from Amazon IP addresses. Our second server running the same setup (hardware spec, OS version, Tomcat version, etc.) and had almost the same session count and our application and Tomcat didn't go unresponsive. Is there any tuneable parameter for the APR connector for Tomcat to close the stuck sessions, rather than waiting for the application? Warm regards, Norbert Elbanbuena - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9.0.36 - JDK 13/14
On 02.07.2020 10:23, Utkarsh Bhargav wrote: Please i have resolved my issue Kindly stop sending mails Hi. You receive these emails because you subscribed to the email list "users@tomcat.apache.org". To not receive these emails anymore, you should unsubscribe from the list, be sending an email (from the same email address which you used to subscribe), *as indicated at the end of every email that you receive from the list*. (including this one) [...] - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: NullPointerException on statrup - possible bug in Tomcat
Problem resolved. Thank you. On Wed, Jun 24, 2020, at 12:46 PM, Konstantin Kolinko wrote: > ср, 24 июн. 2020 г. в 19:25, : > > > > I have a web application which is failing in RestEasy initialization with > > an NPE. It worked for many years until I added a large number of jar > > dependencies because of a new development effort. I've debugged the code by > > stepping through the Tomcat source to the point I've found where it is > > failing. It seems to be a Tomcat bug but of course I'm not convinced since > > it is highly more likely it is my problem. > > > > Tomcat version is 9.0.36, though the failure happens in the Tomcat 8 > > versions I've tried as well. > > > > The NPE is triggered by a single "return null" statement in > > org.apache.catalina.core.ApplicationContext line 933. Below is a code > > snippet of where the return statement is. In my failing scenario the > > wrapper is NOT null and isOverridable is already returning false. So it > > falls through to return null. > > > > So here is my question: Why in the world in the code below does the return > > null statement even exist? It seems like the return null at line 933 is the > > precondition the code is trying to establish. > > This method is documented in the specification of Servlet API (in > their javadoc) to return null if such servlet has already been > registered. > See Java EE 8 javadoc > https://javaee.github.io/javaee-spec/javadocs/javax/servlet/ServletContext.html#addServlet-java.lang.String-java.lang.Class- > > (Following the links from Specifications page > https://cwiki.apache.org/confluence/display/TOMCAT/Specifications > > K.Kolinko > > - > 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
NullPointerException on statrup - possible bug in Tomcat
I have a web application which is failing in RestEasy initialization with an
NPE. It worked for many years until I added a large number of jar dependencies
because of a new development effort. I've debugged the code by stepping through
the Tomcat source to the point I've found where it is failing. It seems to be a
Tomcat bug but of course I'm not convinced since it is highly more likely it is
my problem.
Tomcat version is 9.0.36, though the failure happens in the Tomcat 8 versions
I've tried as well.
The NPE is triggered by a single "return null" statement in
org.apache.catalina.core.ApplicationContext line 933. Below is a code snippet
of where the return statement is. In my failing scenario the wrapper is NOT
null and isOverridable is already returning false. So it falls through to
return null.
So here is my question: Why in the world in the code below does the return null
statement even exist? It seems like the return null at line 933 is the
precondition the code is trying to establish.
//code from 'org.apache.catalina.core.ApplicationContext'
Wrapper wrapper = (Wrapper) context.findChild(servletName);
// Assume a 'complete' ServletRegistration is one that has a class and
// a name
if (wrapper == null) {
wrapper = context.createWrapper();
wrapper.setName(servletName);
context.addChild(wrapper);
} else {
if (wrapper.getName() != null &&
wrapper.getServletClass() != null) {
if (wrapper.isOverridable()) {
wrapper.setOverridable(false);
} else {
return null; // Line 933
}
}
}
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does Tomcat 9 still support AJP connections, REMOTE_USER, and tomcatAuthentication="false"?
In summary, yes, I think you're right in your final conclusion below.
If the tomcat access log shows the authenticated user, it means that tomcat got it, and I
see no other way than from Apache and through that "tomcatAuthentication=false" option of
the tomcat AJP connector.
And that in turn means that, for Apache, this request was authenticated, which in turn
means that OAM /did/ also set the Apache-internal R->user variable.
The values printed by your Apache cgi-bin script are maybe a bit confusing regarding what
is going on, because they are the result of a different (and parallel) process : when
Apache runs a cgi-bin script, it does this in a separate child process, and when it
creates this process, it provides it with an environment. And that is what your cgi-bin
script is showing (it's own environment values).
That in this environment, Apache creates a "remote-user" variable and populates it with
the Apache authenticated user-id, is fortuitous but unrelated to the fact that
Apache+mod_proxy_ajp *also* passes this authenticated user-id via AJP to tomcat.
So now indeed, you have to figure out why this tomcat webapp wants the browser to retrieve
a login page, despite the fact that this access is already authenticated.
But indeed this is no longer an Apache or a tomcat or tomcat Connector issue, it is a
webapp logic or configuration issue.
On 16.05.2020 08:40, ohaya wrote:
Hi,
When I configure the OAM protection, they have the ability to configure values
that go into HTTP headers (among other things) upon successful authentication
(to OAM).
I usually test this by protecting /cgi-bin/printenv on the Apache. printenv has
this :
##
## printenv -- demo CGI program which just prints its environment
##
use strict;
use warnings;
print "Content-type: text/plain; charset=iso-8859-1\n\n";
foreach my $var (sort(keys(%ENV))) {
my $val = $ENV{$var};
$val =~ s|\n|\\n|g;
$val =~ s|"|\\"|g;
print "${var}=\"${val}\"\n";
and when do that test, it does dump out remote_user (among others).
Also FYI, I was just looking at the Tomcat localhost_access_log..txt
file, and I am seeing lines like:
xx.0.xx.xx - [16/May/2020:06:18:41 +] "GET /xxx/login
HTTP/1.1" 302 -
where is the username of the user that authenticated to OAM.
I am not 100% about the format of that log, but does that line say that Tomcat thinks
that the user that is logged INTO TOMCAT is that ?
If so, then does that mean that I am already passing that user from Apache into
Tomcat successfully?
If so, I have thinking that maybe the webapp that I am trying to get logged
into (it is Apache Syncope) is not leveraging the authentication mechanisms
that are inbuilt in Tomcat?
That kind of makes sense, because I know that I didn't have to add that user to
the tomcat-users.xml.
Finally if that is the case, this is no longer just a Tomcat-related issue.
Jim
On Friday, May 15, 2020, 09:38:19 AM EDT, Christopher Schultz
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jim,
On 5/15/20 08:42, ohaya wrote:
Yes, I am using Oracle Access Manager (OAM) so we have what they
call an "OAM webgate" that is integrated with the Apache. That
webgate automatically populates an HTTP header named "remote_user"
with the user that OAM authenticated.
So the problem I having is trying to figure out how to "integrate"
that with Tomcat.
Okay.
So we have:
Browser <==> Apache+webgate <==> Tomcat (webapp)
Good.
First thing's first: Do you get your pages from Tomcat, but you aren't
authenticated, or do you get some other kind of error? Sounds like you
see your application, just no authentication.
If this is your first time doing this, I assume you mean you're trying
to figure out how to get it done, not trying to move a working
configuration from another environment./version to Tomcat 9, right?
There is nothing in the configuration you have posted so far that
leads me to believe you'll be sending any REMOTE_USER HTTP header to
Tomcat. Apache httpd doesn't (usually) auto-forward anything to
Tomcat. Your OAS module is more likely setting an environment variable
(remote_user) than an HTTP header. But it might be setting a header.
That would be good information to know.
To send arbitrary headers (etc.) to Tomcat via mod_proxy_ajp, you need
to configuration to do that. Let's take a look at the Tomcat
documentation to see how tomcatAuthentication="false" works.
Awesome, the documentation says nothing about how to tie-into it.
Well, the code says that tomcatAuthentication="false" means that AJP
can accept the REMOTE_USER /request attribute/ which is a special
servlet-thing which isn't the same as a header. So you have to arrange
for mod_proxy_ajp to send your "remote_user" (header or environment
variable) to Tomcat as a request attribute.
Here's how to do that.
Re: Does Tomcat 9 still support AJP connections, REMOTE_USER, and tomcatAuthentication="false"?
On 15.05.2020 14:42, ohaya wrote: Hi, Yes, I am using Oracle Access Manager (OAM) so we have what they call an "OAM webgate" that is integrated with the Apache. That webgate automatically populates an HTTP header named "remote_user" with the user that OAM authenticated. So the problem I having is trying to figure out how to "integrate" that with Tomcat. Then you would need an Apache add-on module which grabs the content of this header, and sets the Apache R->user variable (where R is the Apache request object). And in Tomcat, your Connector, as it is shown below, will automatically pick up this user-id and use it within tomcat. There is probably already an option in OAM which does this (set the Apache user at the same time as adding that HTTP header REMOTE_USER). That is what it should do anyway, if OAM can also authenticate the user for an application running within Apache. So we have: Browser <==> Apache+webgate <==> Tomcat (webapp) Jim On Friday, May 15, 2020, 08:36:18 AM EDT, André Warnier (tomcat/perl) wrote: Let me give my 5 cent. In the tomcat AJP Connector Tomcat, you use the tomcatAuthentication attribute : This setting has the effect that tomcat will "believe" the authenticated user-id that Apache is passing to it in the AJP protocol messages that Apache sends to tomcat, and not try to re-authenticate again at the tomcat level. (Note : this is not done by a "REMOTE_USER" HTTP header added by Apache; it happens via some internal variable specific to the AJP protocol). Of course, for this, the request needs to be first authenticated in Apache (so that it has a user-id to pass to tomcat). So do you have anything at the Apache httpd side, which authenticates the user before the request gets passed to tomcat (via AJP) ? On 15.05.2020 14:08, ohaya wrote: Hi Olaf, Thanks. I do appreciate that! I will do more digging. Jim On Friday, May 15, 2020, 07:41:50 AM EDT, Olaf Kock wrote: On 15.05.20 13:23, ohaya wrote: Hi, I just tried adding the secret to the Apache side: ProxyPass ajp://192.168.218.XXX:8009 secret="123" ProxyPassReverse ajp://192.168.218.XXX:8009 secret="123" and I get an error when I try to start Apache: AH00526: Syntax error on line 554 of /apps/oracle/apache/conf/httpd.conf: ProxyPass unknown Worker parameter I am currently using Apache 2.4.39. Is there another way to specify the "secret"? With 9.0.20 you do not yet need to pass a secret - that came along later (somewhere around 30-33 AFAIR). However, you'll need to make sure that your AJP port is only available for the reverse proxy and nobody else - there was a recent security disclosure, which led to the change of many default settings for the AJP connector in the current releases. It boils down to the last sentence of my previous answer: I've never used REMOTE_USER headers for authentication, and there's no indicator in your setup that you're allowing Tomcat to trust such a header. I might be completely off here, but as nobody else answered yet, I thought I'd give it a try. Olaf Thanks, Jim On Friday, May 15, 2020, 07:04:44 AM EDT, ohaya wrote: Hi, The Tomcat version I am using is 9.0.20. I will take a look at the changelog. This is the first time I have tried this, and I couldn't find much info, so I appreciate the feedback. I will look for info about "secret". I wasn't sure about the format on the Apache side for the ProxyPass/ProxyPassReverse - does what I posted look all right? Also, when I was searching around for info, I saw some comments that seem to be saying that the "tomcatAuthentication" parameter on the Tomcat connection was no longer supported or something like that? Also re. "secret" on the Tomcat side: If that is set to, for example, "mysecret", how do I pass that on the Apache side? Thanks again, Jim On Friday, May 15, 2020, 03:33:19 AM EDT, Olaf Kock wrote: On 15.05.20 09:06, oh...@yahoo.com.INVALID wrote: Hi, I am using an Apache proxy in front of Tomcat 9, and I am using AJP connection to connect from the Apache to Tomcat, and I have the Apache sending a username to the Tomcat in a REMOTE_USER header. In the Tomcat server.xml I have: In the Apache httpd.conf, to test, this I have: ProxyPass ajp://192.168.218.XX:8009 ProxyPassReverse ajp://192.168.XX.224:8009 But when I access the app via the Apache, it is not automatically logging me into the app. Is there anything else that I have to do to get this to work besides what I did above? Is there something that I have to modify in the app itself to get this to work? Hi Jim, which exact version of Tomcat 9 are you using? Note that there were significant changes for the default and required configuration for the AJP connector, in order to use it. Best to f
Re: Does Tomcat 9 still support AJP connections, REMOTE_USER, and tomcatAuthentication="false"?
Let me give my 5 cent. In the tomcat AJP Connector Tomcat, you use the tomcatAuthentication attribute : This setting has the effect that tomcat will "believe" the authenticated user-id that Apache is passing to it in the AJP protocol messages that Apache sends to tomcat, and not try to re-authenticate again at the tomcat level. (Note : this is not done by a "REMOTE_USER" HTTP header added by Apache; it happens via some internal variable specific to the AJP protocol). Of course, for this, the request needs to be first authenticated in Apache (so that it has a user-id to pass to tomcat). So do you have anything at the Apache httpd side, which authenticates the user before the request gets passed to tomcat (via AJP) ? On 15.05.2020 14:08, ohaya wrote: Hi Olaf, Thanks. I do appreciate that! I will do more digging. Jim On Friday, May 15, 2020, 07:41:50 AM EDT, Olaf Kock wrote: On 15.05.20 13:23, ohaya wrote: Hi, I just tried adding the secret to the Apache side: ProxyPass ajp://192.168.218.XXX:8009 secret="123" ProxyPassReverse ajp://192.168.218.XXX:8009 secret="123" and I get an error when I try to start Apache: AH00526: Syntax error on line 554 of /apps/oracle/apache/conf/httpd.conf: ProxyPass unknown Worker parameter I am currently using Apache 2.4.39. Is there another way to specify the "secret"? With 9.0.20 you do not yet need to pass a secret - that came along later (somewhere around 30-33 AFAIR). However, you'll need to make sure that your AJP port is only available for the reverse proxy and nobody else - there was a recent security disclosure, which led to the change of many default settings for the AJP connector in the current releases. It boils down to the last sentence of my previous answer: I've never used REMOTE_USER headers for authentication, and there's no indicator in your setup that you're allowing Tomcat to trust such a header. I might be completely off here, but as nobody else answered yet, I thought I'd give it a try. Olaf Thanks, Jim On Friday, May 15, 2020, 07:04:44 AM EDT, ohaya wrote: Hi, The Tomcat version I am using is 9.0.20. I will take a look at the changelog. This is the first time I have tried this, and I couldn't find much info, so I appreciate the feedback. I will look for info about "secret". I wasn't sure about the format on the Apache side for the ProxyPass/ProxyPassReverse - does what I posted look all right? Also, when I was searching around for info, I saw some comments that seem to be saying that the "tomcatAuthentication" parameter on the Tomcat connection was no longer supported or something like that? Also re. "secret" on the Tomcat side: If that is set to, for example, "mysecret", how do I pass that on the Apache side? Thanks again, Jim On Friday, May 15, 2020, 03:33:19 AM EDT, Olaf Kock wrote: On 15.05.20 09:06, oh...@yahoo.com.INVALID wrote: Hi, I am using an Apache proxy in front of Tomcat 9, and I am using AJP connection to connect from the Apache to Tomcat, and I have the Apache sending a username to the Tomcat in a REMOTE_USER header. In the Tomcat server.xml I have: In the Apache httpd.conf, to test, this I have: ProxyPass ajp://192.168.218.XX:8009 ProxyPassReverse ajp://192.168.XX.224:8009 But when I access the app via the Apache, it is not automatically logging me into the app. Is there anything else that I have to do to get this to work besides what I did above? Is there something that I have to modify in the app itself to get this to work? Hi Jim, which exact version of Tomcat 9 are you using? Note that there were significant changes for the default and required configuration for the AJP connector, in order to use it. Best to find all of them: Search for AJP in the change log tomcat.apache.org/tomcat-9.0-doc/changelog.html Notable among them: Everything to do with "secret", and the default bind address, "localhost", for the AJP connector. i.e. I'd expect this configuration to be insufficient for any of the latest releases. I haven't ever used this REMOTE_USER authentication, but nothing in the configuration that you've posted gives any clue about what you do and what you send. I would expect Tomcat to *not* blindly accept any REMOTE_USER header by default, unless it's whitelisted and explicitly asked for - it otherwise would be a great way to exploit servers that don't have a remote proxy (or one where the remote proxy is configured to remove this header). Nothing in the configuration you post gives me a hint about what you do to make tomcat accept and trust this header. Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --
Re: Changing the Java using by Tomcat
On 06.05.2020 10:55, Reddy, Tippana Krishnanandan wrote: Hi All, We are using tomcat 9.0.6 and we want to change existing JAVA used by tomcat and replace it Adopt openJDK without uninstalling the tomcat. Is this possible? if so can anyone please send us details how to approach this. I don't think that there is anything in the tomcat configuration itself that must be changed. It will consists mostly of changes to the tomcat startup scripts. Under what OS are you running tomcat ? and how was it installed ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Upgrading from 9.0.20 to 9.0.34 AJP connector issue
On 01.05.2020 20:32, Darryl Philip Baker wrote: Continuing the investigation: I have the two tomcat installation in /opt/tomcat. Apache HTTPD references the worker file using a path that has a symbolic link that "latest" I can switch to point to either installation of tomcat. The workers file is defined in httpd.conf as "JkWorkersFile /opt/tomcat/latest/conf/jk/workers.properties" Tomcat 9.0.20 works as expected. Tomcat 9.0.34 fails with just having the browser clocking and not returning. I think you may have gotten everyone confused now because 1) you cannot have 2 different tomcat installations under the same directory (/opt/tomcat in your above explanation) 2) previously, you wrote that the error in one case was that you got back a 404 error. Now you are saying that the browser is just waiting and "not returning". 3) in the diff output below, it seems that you have a line like >> worker.worker1.secret="false" in one of the "server.xml" files (although it appears to be part of a comment). That is not where such a line belongs. Can you be more precise in exactly describing your installation, how you are starting one tomcat or the other, how you switch between them, and what happens ? P.S. I would recommend moving yourt workers.properties file away from the tomcat directories, and into some httpd configuration directory, because that file has in fact nothing to do with tomcat. It is read by the mod_jk module, which is a module running in httpd, not tomcat. Just to give you an idea of the differences in the control files: [[root@lmsdevsyncapp7 tomcat]# diff apache-tomcat-9.0.20/conf/server.xml apache-tomcat-9.0.34/conf/server.xml 79c79 < 119d121 < address="127.0.0.1" [root@lmsdevsyncapp7 tomcat]# diff apache-tomcat-9.0.20/conf/jk/workers.properties apache-tomcat-9.0.34/conf/jk/workers.properties [root@lmsdevsyncapp7 tomcat]# ls -l total 8 drwxrwxr-x 9 tomcat tomcat 4096 May 16 2019 apache-tomcat-9.0.20 drwxr-xr-x 9 tomcat tomcat 4096 Apr 28 11:59 apache-tomcat-9.0.34 lrwxrwxrwx 1 root root 20 Apr 28 15:00 latest -> apache-tomcat-9.0.34 [root@lmsdevsyncapp7 tomcat]# Darryl Baker, GSEC (he/him/his) Sr. System Administrator Distributed Application Platform Services Northwestern University 1800 Sherman Ave. Suite 6-600 – Box #39 Evanston, IL 60201-3715 darryl.ba...@northwestern.edu (847) 467-6674 On 4/30/20, 5:09 PM, "Darryl Philip Baker" wrote: I am trying to browse to one of the JKmount URLs in this case https://myserver.northwestern.edu/LmsSync/. When I point the symbolic link to the 9.0.20 installation, it works fine. When I point the symbolic link to the 9.0.34 installation, it I get a 404 error. Darryl Baker, GSEC (he/him/his) Sr. System Administrator Distributed Application Platform Services Northwestern University 1800 Sherman Ave. Suite 6-600 – Box #39 Evanston, IL 60201-3715 darryl.ba...@northwestern.edu (847) 467-6674 On 4/30/20, 3:35 PM, "Christopher Schultz" wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Darryl, On 4/30/20 07:59, Darryl Philip Baker wrote: > I am trying to upgrade a development environment from 9.0.20 to > 9.0.34 and I am having issues getting the tomcat-connectors-1.2.46 > (mod_jk) to work in with the new version. Can you be more specific? What are you trying, and how is it (not) working, specifically? > The Apache HTTPD configuration remains unchanged the paths pass > through a symbolic link I change to switch versions. The > workers.properties file was copied over and is identical. I added > the same definition for the AJP connector into server.xml. I will > place the pieces I modified below.> Server.xml: protocol="AJP/1.3" redirectPort="443" address="127.0.0.1" > enableLookups="false" tomcatAuthentication="false" > secretRequired="false" maxPostSize="10" /> > > Workers.properties: #define 1st worker using worker1 > worker.list=worker1 > > #set properties for the worker1 worker worker.worker1.type=ajp13 > worker.worker1.host=127.0.0.1 worker.worker1.port=8009 > worker.worker1.lbfactor=50 worker.worker1.cachesize=10 > worker.worker1.cache_timeout=600 worker.worker1.socket_keepalive=1 > worker.worker1.recycle_timeout=300 At first glance, this configuration looks fine to me. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://urldefense.com/v3/__https://www.enigmail.net/__;!!Dq0X2DkFhyF93HkjWTBQ
Re: Upgrading from 9.0.20 to 9.0.34 AJP connector issue
On 01.05.2020 00:09, Darryl Philip Baker wrote: I am trying to browse to one of the JKmount URLs in this case https://myserver.northwestern.edu/LmsSync/. When I point the symbolic link to the 9.0.20 installation, it works fine. When I point the symbolic link to the 9.0.34 installation, it I get a 404 error. Ah, here may be a clue : the 404 error page returned by Apache httpd looks significantly different from the 404 error page returned by Tomcat (in look). Which one are you getting ? If you get the Apache httpd version, then the problem is that Apache httpd/mod_jk is not even trying to forward the call to Tomcat, and tries to map it locally to the Apache document space. Conversely, if you get the Tomcat version, then it means that the call /is/ forwarded by httpd/mod_jk to Tomcat, but that it is tomcat somehow which does not find anything in its URL space that matches the forwarded link URL. Darryl Baker, GSEC (he/him/his) Sr. System Administrator Distributed Application Platform Services Northwestern University 1800 Sherman Ave. Suite 6-600 – Box #39 Evanston, IL 60201-3715 darryl.ba...@northwestern.edu (847) 467-6674 On 4/30/20, 3:35 PM, "Christopher Schultz" wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Darryl, On 4/30/20 07:59, Darryl Philip Baker wrote: > I am trying to upgrade a development environment from 9.0.20 to > 9.0.34 and I am having issues getting the tomcat-connectors-1.2.46 > (mod_jk) to work in with the new version. Can you be more specific? What are you trying, and how is it (not) working, specifically? > The Apache HTTPD configuration remains unchanged the paths pass > through a symbolic link I change to switch versions. The > workers.properties file was copied over and is identical. I added > the same definition for the AJP connector into server.xml. I will > place the pieces I modified below.> Server.xml: protocol="AJP/1.3" redirectPort="443" address="127.0.0.1" > enableLookups="false" tomcatAuthentication="false" > secretRequired="false" maxPostSize="10" /> > > Workers.properties: #define 1st worker using worker1 > worker.list=worker1 > > #set properties for the worker1 worker worker.worker1.type=ajp13 > worker.worker1.host=127.0.0.1 worker.worker1.port=8009 > worker.worker1.lbfactor=50 worker.worker1.cachesize=10 > worker.worker1.cache_timeout=600 worker.worker1.socket_keepalive=1 > worker.worker1.recycle_timeout=300 At first glance, this configuration looks fine to me. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6rNncACgkQHPApP6U8 pFh5nA//RMgbj+pgTSUqUq7zUaFvzEudyp3kfGDI7As7uvmE2BOwYABPtXjKniRF 2r/whNKQDu8VGOAp1JwTamPGpuNSh9pHW8KVqoTkr3Hg47E9fl86zE3a33/Gzq4G Q72SZNmIyZtDvkf7autdSUXUeb1DX4KJcX7O42c7TzYp6APb82u/NUwDLRBD24FK dVkMtkdoUgG19tsjLVNalGRkTgBNHC1ySIFikn0Tsd/28ApxCOtApn5Y85JxkjNh GwoxbFXjTtGDVVq3Yo039xelALdquk9mm5BdA1UyANTcOx1s2VZozlVy1ayPMHNm zPgqWLdhgRipAiLqDrPiE4u1R1PQ9wr/klQragHwY5LTzby8x1V7PAn4RZw0BRrt yPCIAoI+dEnsiMRxfnVuNYHYbqMjTKlEF4M2zBKYuq6bpGKZEw8/IoK86kEAFYR5 trVt3o2uJ/qhn/34m4F30ilTXm7DR389ZaZ83nF4dihsst9aNmZuSUCZ6qEHTbNC Tk1v7p+GxMJQwLglr63hfhNTij3zJPbZjQ9NXza7UiLYqqkzStXJX9JeUCjHmKsq V6Ageh0STQm7zjRSsFse0QGP21anIxqmzkD6MmZE85v0Wsbe5gEzHXvGVpb5NdHe ClWrI8H94YGG9XeZePvD2hlMNwCwATqJlev+IKk5WyPE+zI8BkM= =NL+W -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: Losing session between calls from mobile phone
On 28.04.2020 18:28, AJ Chen wrote: Thanks. Martin and Mark. I can recreate the problem: I compare two different mobile phones. One phone can log in and proceed. Server log shows the same session persists (same sessionID upon different requests). The other phone can log in, but upon next request, server log show a new session is always created (new sessionId). Since session tracking works on PC browser and some mobile phone, the proxy (if any) in front of aws EC2 server should not be the problem.Anything else may be missing? Asking just in case : - are the 2 phones on the same network carrier ? - are they the same brand, or at least OS ? - if you connect them both to the same local WiFi, do they still act differently ? Note : no idea if this makes any difference, but we're trying to find a reason why they act differently when using the same Internet application server, right ? -aj On Tue, Apr 28, 2020 at 12:30 AM Mark Thomas wrote: On 28/04/2020 07:47, Martin Grigorov wrote: On Tue, Apr 28, 2020 at 9:11 AM AJ Chen wrote: Anyway to fix it? thanks. -aj First you need to investigate whether there is a proxy. Then what kind of proxy. Then where is its configuration. Then consult with its manual and see whether there is something wrong/missng. I'd recommend taking a step back. Guessing at what might be wrong and then trying to fix the problem you have only guessed at is unlikely to work. Can you recreate the problem? You can't tell if something is fixed if you can't recreate it. Once you recreate the problem then you can start to narrow it down. You need to track what is happening to the session ID. You'll probably need to add some information to the access log, possibly look at some raw network logs and/or look at HTTP headers on the client.. Somewhere in all of the above you should find out where the session ID is getting dropped. Then you need to figure out why. Only then you know why this is happening can you start to think about a solution. Mark On Mon, Apr 27, 2020 at 10:54 PM Martin Grigorov wrote: Hi, On Tue, Apr 28, 2020 at 2:23 AM AJ Chen wrote: My web application using tomcat 6 can track user session (cookie by default) for mobile and PC users in dev environment. But when deployed on cloud server, it fails to track session for some mobile users. meaning, servlet always creates a new session upon user request. Any idea why this happens? Most probably there is a proxy in front of Tomcat in the cloud environment which does not properly forward the JSESSIONID cookie. Martin aj - 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: Why does Tomcat open connections on localhost?
On 31.03.2020 15:30, Mark Thomas wrote: On 31/03/2020 13:29, André Warnier (tomcat/perl) wrote: On 31.03.2020 14:20, Mark Thomas wrote: On 31/03/2020 11:20, Aditya Kumar wrote: Tomcat 9.0.30 on Windows Server 2012 / Java 1.8 I've noticed on a freshly installed version of tomcat 9, upon startup there are several connections to and from localhost on different ports For example on my tomcat server there are 4 connections to and from localhost (output from netstat) TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 3972 TCP 127.0.0.1:55618 127.0.0.1:55619 ESTABLISHED 3972 TCP 127.0.0.1:55619 127.0.0.1:55618 ESTABLISHED 3972 TCP 127.0.0.1:55620 127.0.0.1:55621 ESTABLISHED 3972 TCP 127.0.0.1:55621 127.0.0.1:55620 ESTABLISHED 3972 TCP [::]:8080 [::]:0 LISTENING 3972 These can grow to a large number (several thousand) on a busy system. What are these connections used for? What caused them? What thread are they attributed to? The Java NIO implementation on Windows uses TCP for intra-process signalling. It opens a pair of self-connected sockets for every Selector. Mark While we're at it, under Linux, are the following for a similar reason ? output of : netstat -pan | grep 27514 (tomcat's JVM PID = 27514) [...] unix 2 [ ] STREAM CONNECTED 167427210 27514/java unix 2 [ ] STREAM CONNECTED 167423436 27514/java Don't know. One possible way to check would be to add an additional NIO connector and see if you get more of them. Note : this is not very important, was just curiosity But Nope. I added a second HTTP Connector (port 8180), which by default should be NIO : and restarted tomcat, but the number of listed unix sockets remains the same : root@xxx:~# netstat -pan | grep 32647 (tomcat 8.5 has a new PID) tcp6 0 0 127.0.0.1:8005 :::*LISTEN 32647/java tcp6 0 0 127.0.0.1:8009 :::*LISTEN 32647/java tcp6 0 0 :::8080 :::*LISTEN 32647/java tcp6 0 0 127.0.0.1:8180 :::*LISTEN 32647/java tcp6 0 0 127.0.0.1:8009 127.0.0.1:45190 ESTABLISHED 32647/java unix 2 [ ] STREAM CONNECTED 190838270 32647/java unix 2 [ ] STREAM CONNECTED 190846897 32647/java root@darwin:~# - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does Tomcat open connections on localhost?
On 31.03.2020 14:20, Mark Thomas wrote: On 31/03/2020 11:20, Aditya Kumar wrote: Tomcat 9.0.30 on Windows Server 2012 / Java 1.8 I've noticed on a freshly installed version of tomcat 9, upon startup there are several connections to and from localhost on different ports For example on my tomcat server there are 4 connections to and from localhost (output from netstat) TCP0.0.0.0:8080 0.0.0.0:0 LISTENING 3972 TCP127.0.0.1:55618127.0.0.1:55619ESTABLISHED 3972 TCP127.0.0.1:55619127.0.0.1:55618ESTABLISHED 3972 TCP127.0.0.1:55620127.0.0.1:55621ESTABLISHED 3972 TCP127.0.0.1:55621127.0.0.1:55620ESTABLISHED 3972 TCP[::]:8080 [::]:0 LISTENING 3972 These can grow to a large number (several thousand) on a busy system. What are these connections used for? What caused them? What thread are they attributed to? The Java NIO implementation on Windows uses TCP for intra-process signalling. It opens a pair of self-connected sockets for every Selector. Mark While we're at it, under Linux, are the following for a similar reason ? output of : netstat -pan | grep 27514 (tomcat's JVM PID = 27514) [...] unix 2 [ ] STREAM CONNECTED 167427210 27514/java unix 2 [ ] STREAM CONNECTED 167423436 27514/java - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does Tomcat/Java get around the problem of 64K maximum client source ports?
On 27.03.2020 21:39, Eric Robinson wrote: FYI, I don't have 1800 tomcat instances on one server. I have about 100 instances on each of 18 servers. When one of these (attempted) connections fails, do you not get some error message which gives a clue as to what the failure is due to ? (should be a log somewhere, no ?) Also, just for info : in the past, I have run into problems under Linux (no more connections accepted, neither incoming nor outgoing) whenever the actual number of TCP connections went above a certain number (maybe it was 64K). A TCP connection goes through a number of states (which you see with a netstat display), such as "ESTABLISHED" but also "TIME_WAIT", "CLOSE_WAIT" etc.. In some of these states, the connection no longer has any link to any process, but the connection still counts against the limit (of the OS/TCP stack). The case I'm talking about was a bit like yours : a webapp running under tomcat was making a connection to a remote host, but this connection was wrapped inside an object of some kind. When the webapp no longer needed the connection, it just discarded the wrapping object, which was left without references to it, and thus candidate for destruction at some point. But the discarded object never explicitly closed the underlying connection. Over a period of time, this left an accumulation of (no longer used) connections in the "CLOSE_WAIT" state (closed by the remote host side, but not by the webapp side), which just sat there until a GC happened, at which time the destruction of these objects really happened, and some implicit close was done at the OS level, which eliminated these pending underlying CLOSE_WAIT connections. And since the available heap was quite large, it took a long time before a GC happened, which allowed such CLOSE_WAIT connections to accumulate in the hundreds or thousands before being "recycled". Until a certain number was reached, and then the host became all but unreachable and very slow. That was a long time ago, and thus a lot of Java versions and Linux versions ago, so maybe something happened since then to avoid such a situation. But maybe also, you are suffering of some similar phenomenon. You could try to use netstat some more, and when you are having the problem, you should count at ALL the TCP connections, including the ones in CLOSE_WAIT, and just check if you do not have an obscene number of them in total. There is definitely some limit number past which the OS starts acting funny. (Note : unlike for TIME_WAIT e.g., there is no time limit for a connection in the CLOSE_WAIT state; it will stay in that state as long as the client side has not explicitly closed it, in some kind of zombie half-life) See e.g. : https://users.cs.northwestern.edu/~agupta/cs340/project2/TCPIP_State_Transition_Diagram.pdf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does Tomcat/Java get around the problem of 64K maximum client source ports?
On 27.03.2020 14:27, André Warnier (tomcat/perl) wrote: On 26.03.2020 20:42, Eric Robinson wrote: -Original Message- From: Olaf Kock Sent: Thursday, March 26, 2020 2:06 PM To: users@tomcat.apache.org Subject: Re: Does Tomcat/Java get around the problem of 64K maximum client source ports? Hi Eric, On 26.03.20 18:58, Eric Robinson wrote: Greetings, Many people say the maximum number of client ports is 64K. However, TCP connections only require unique sockets, which are defined as... local_IP:local_port -> remote_ip:remote_port Theoretically, it is possible for a client process to keep using the same local source port, as long as the connections are to a unique destinations. For example on a local machine, the following connections should be possible... 192.168.5.100:1400 -> 192.168.5.200:3306 192.168.5.100:1400 -> 192.168.5.201:3306 192.168.5.100:1400 -> 192.168.5.202:3306 192.168.5.100:1400 -> 192.168.5.203:3306 I've seen this demonstrated successfully here: https://serverfault.com/questions/326819/does-the-tcp-source-port-have -to-be-unique-per-host As someone on that page pointed out, while it is possible, it does not commonly occur in practice "because most TCP APIs don't provide a way to create more than one connection with the same source port, unless they have different source IP addresses." This leads to the 64K maximum client port range, but it is really a limitation of the APIs, not TCP. So how does tomcat handle things? Is it limited to a maximum 64K client source ports, or is it 64K per destination, as it should be? To be honest, I can't remember to have seen a web- or application server that accepts 64K concurrent connections at all, let alone to a single client. I can't come up with any reason to do so, I'd assume that there's a DOS attack if I get 100 concurrent incoming connections from a single IP, and a programming error if the server sets up more than 1K outgoing connections Maybe I'm missing the obvious, or have only administered meaningless installations, but I fail to see the real world relevance of this question. I don't blame you for being puzzled, but this not about tomcat accepting connections. It's about tomcat acting as the client, where MySQL is the server. I'm referring to client connections from tomcat to MySQL. We have about 1800 instances of tomcat running. This question comes up once in a while when tomcat can't connect to MySQL. Trust me, it can be an issue. --Eric The question is : is there even any Java API (method) (or even OS API) which allows a client to open a (client, non-LISTEN) socket AND specify the client IP address and/or port ? I mean, if there is none, then the question may be interesting in the absolute, but ultimately pointless. I believe that the IP address of client packets, will be determined by which /route/ the OS determines that the target server address can be reached (which will determine through which network interface the packets "go out", which will determine the sender IP address inserted in the packets). I don't think that the application-level software (here a java webapp) can determine this in advance. And the client port will be decided by the OS-level TCP stack, in function of which ones are not yet in use (which a java webapp can also not determine in advance). Example of creating a client socket : Socket echoSocket = new Socket(hostName, portNumber); The hostname (or IP address of ditto) and port numbers passed as arguments, are the IP:port of the server you are connecting /to/, not the ones of the local socket. Addendum : https://stackoverflow.com/questions/11129212/tcp-can-two-different-sockets-share-a-port/11129641 From which I gather that, although it may be possible (in some languages or using some API) to open several client connections (to different target IP/port) using the same local port number, you may still have other issues when doing this : - the host's TCP/IP stack has to keep track of all the simultaneous connections, and if the list gets very large, this may become very resource-intensive - there may be a limit at the OS level, to how many sockets are allowed at the same time - to each connection, corresponds some kind of a "file descriptor". There may be limits, at the process level (in this case the JVM running tomcat), or even at the host level, to how many of those may be in use at any one time (So if you were running on a host one JVM for a tomcat instance, it would compete with other processes running on the same host and also using file descriptors) It seems also thus possible that the reason why you are running against a problem not being able to make additional connections to a MySql server, is not necessarily the usage of all 64K port numbers, but one of the other limitations above. - To unsubscribe, e-mail: users-unsubscr
Re: Does Tomcat/Java get around the problem of 64K maximum client source ports?
On 26.03.2020 20:42, Eric Robinson wrote: -Original Message- From: Olaf Kock Sent: Thursday, March 26, 2020 2:06 PM To: users@tomcat.apache.org Subject: Re: Does Tomcat/Java get around the problem of 64K maximum client source ports? Hi Eric, On 26.03.20 18:58, Eric Robinson wrote: Greetings, Many people say the maximum number of client ports is 64K. However, TCP connections only require unique sockets, which are defined as... local_IP:local_port -> remote_ip:remote_port Theoretically, it is possible for a client process to keep using the same local source port, as long as the connections are to a unique destinations. For example on a local machine, the following connections should be possible... 192.168.5.100:1400 -> 192.168.5.200:3306 192.168.5.100:1400 -> 192.168.5.201:3306 192.168.5.100:1400 -> 192.168.5.202:3306 192.168.5.100:1400 -> 192.168.5.203:3306 I've seen this demonstrated successfully here: https://serverfault.com/questions/326819/does-the-tcp-source-port-have -to-be-unique-per-host As someone on that page pointed out, while it is possible, it does not commonly occur in practice "because most TCP APIs don't provide a way to create more than one connection with the same source port, unless they have different source IP addresses." This leads to the 64K maximum client port range, but it is really a limitation of the APIs, not TCP. So how does tomcat handle things? Is it limited to a maximum 64K client source ports, or is it 64K per destination, as it should be? To be honest, I can't remember to have seen a web- or application server that accepts 64K concurrent connections at all, let alone to a single client. I can't come up with any reason to do so, I'd assume that there's a DOS attack if I get 100 concurrent incoming connections from a single IP, and a programming error if the server sets up more than 1K outgoing connections Maybe I'm missing the obvious, or have only administered meaningless installations, but I fail to see the real world relevance of this question. I don't blame you for being puzzled, but this not about tomcat accepting connections. It's about tomcat acting as the client, where MySQL is the server. I'm referring to client connections from tomcat to MySQL. We have about 1800 instances of tomcat running. This question comes up once in a while when tomcat can't connect to MySQL. Trust me, it can be an issue. --Eric The question is : is there even any Java API (method) (or even OS API) which allows a client to open a (client, non-LISTEN) socket AND specify the client IP address and/or port ? I mean, if there is none, then the question may be interesting in the absolute, but ultimately pointless. I believe that the IP address of client packets, will be determined by which /route/ the OS determines that the target server address can be reached (which will determine through which network interface the packets "go out", which will determine the sender IP address inserted in the packets). I don't think that the application-level software (here a java webapp) can determine this in advance. And the client port will be decided by the OS-level TCP stack, in function of which ones are not yet in use (which a java webapp can also not determine in advance). Example of creating a client socket : Socket echoSocket = new Socket(hostName, portNumber); The hostname (or IP address of ditto) and port numbers passed as arguments, are the IP:port of the server you are connecting /to/, not the ones of the local socket. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
gostCat patch
Hello tomcat developers. Re : current : https://tomcat.apache.org/tomcat-8.5-doc/config/ajp.html#Standard_Implementations quote secretRequired If this attribute is true, the AJP Connector will only start if the secret attribute is configured with a non-null, non-zero length value. This attribute only controls whether the secret attribute is required to be specified for the AJP Connector to start. It does not control whether workers are required to provide the secret. The default value is true. This attribute should only be set to false when the Connector is used on a trusted network. unquote The above new feature/default has been creating a lot of issues, particularly for sysadmins, who upgrade to what looks like a minor version level, and find their front-end/back-end configurations not working anymore. (Because previously, they did not specify this attribute at all, which defaulted to "false"). In many cases, this will happen even though the front-end httpd (or IIS) and the back-end (tomcat) are in fact running on the same host (*), and thus using the loopback interface to communicate (which also fits well with the new default for "address", which is the loopback address). To avoid such surprises for sysadmins, how about the following suggested change, to the documentation and to the underlying code : quote secretRequired If this attribute is true, the AJP Connector will only start if the secret attribute is configured with a non-null, non-zero length value. This attribute only controls whether the secret attribute is required to be specified for the AJP Connector as they did previouslyto start. It does not control whether workers are required to provide the secret. This attribute should only be set to false when the Connector is used on a trusted network. In consequence and as a hint : The *default* of this attribute is "false", when the "address" attribute is explicitly set to "127.0.0.1" or "::1", or when it defaults to the loopback address. The *default* of this attribute is "true", when the "address" attribute is set to any other IP address. unquote The point is to make sure that existing configurations, which often concern a front-end and a back-end running on the same host, and which often do not contain an explicit "secretRequired" AJP Connector attribute, would default to working as they did before, but *only if* the connection is deemed secure anyway, because it is local. I believe that this alone would already greatly reduce the "stress" caused by this security-related configuration change. (*) I currently manage about 30 Apache httpd / tomcat combinations, and in all of them but one, they are on the same host. And from a historical perspective, I believe that is true for the majority of httpd/tomcat installations except large load-balancing configurations. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: AW: AJP Connector issue
Hi Florian.
The log below shows clearly "The AJP Connector is configured with
secretRequired="true"".
This probably comes from the fact that in your AJP Connector configuration, you
either
- have an explicit secretRequired="true" attribute
or
- you do not mention this attribute, and it defaults to "true"
To get the previous behaviour (without secret), you now *must* specify :
secretRequired="false".
This is one of the changes in the latest tomcat versions compared to the previous one, and
this was motivated by security reasons.
So I doubt that there is any chance for that change to be reversed.
On 20.03.2020 13:49, Fritze, Florian wrote:
Just to make it clear what from my opinion the problem is:
SCHWERWIEGEND [main] org.apache.catalina.core.StandardService.startInternal
Failed to start connector [Connector[AJP/1.3-8011]]
org.apache.catalina.LifecycleException: Der Start des
Protokoll-Handlers ist fehlgeschlagen
at
org.apache.catalina.connector.Connector.startInternal(Connector.java:1057)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:440)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:766)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.startup.Catalina.start(Catalina.java:688)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474)
Caused by: java.lang.IllegalArgumentException: The AJP Connector is configured with
secretRequired="true" but the secret attribute is either null or "". This
combination is not valid.
at
org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.java:274)
at
org.apache.catalina.connector.Connector.startInternal(Connector.java:1055)
... 12 more
This new "secretRequired" attribute prevents the Tomcat from starting
flawlessly. It was first introduced with the Ghostcat release.
So this is a wish from me to the Tomcat developers: Please set this new
attribute not mandatory but optional. So that I can run the newest Tomcat
without this attribute which I do now with the pre-Ghostcat releases.
Have a nice weekend
Florian Fritze
--
Florian Fritze M.A.
Fraunhofer-Informationszentrum Raum und Bau IRB
Competence Center Research Services & Open Science
Nobelstr. 12, 70569 Stuttgart, Germany
Telefon +49 711 970-2713
florian.fri...@irb.fraunhofer.de | www.irb.fraunhofer.de
-Ursprüngliche Nachricht-
Von: André Warnier (tomcat/perl)
Gesendet: Freitag, 20. März 2020 13:34
An: users@tomcat.apache.org
Betreff: Re: AW: AW: AJP Connector issue
Ok, so it looks like :
- the request is effectively reaching tomcat, and that it is tomcat sending
back the 403 response.
- the URL is "/", so presumably it is "well-formed" etc.
Furthermore, according to something you wrote below, both Apache httpd and
tomcat are running on the same Linux host.
This reminds me vaguely of some issue previously (and recently) discussed on
the list, with some request attributes which tomcat did not like..
But I do not remember ptecisely what the issue was, and it also seems to me
that this concerned an IIS front-end, not Apache httpd.
Perhaps someone else on the list has a better idea.
Incidentally, it also seems that you are, in httpd, proxying *all* requests to
tomcat.
Which raises the question of why you have a httpd front-end in the first place.
(But that's a later discussion maybe, let's first see why "/" doesn't work)
On 20.03.2020 11:07, Fritze, Florian wrote:
Here is the additional information:
The error page looks like Tomcat:
HTTP Status 403 – Forbidden
_
Type Status Report
Beschreibung Der Server hat die Anfrage verstanden, verbietet aber eine
Autorisierung.
_
Apache Tomcat/8.5.53
The Apache HTTPD log file says:
- "" [20/Mar/2020:10:56:24 +0100] "GET / HTTP/1.1" 403 1042 "-" "Mozilla/5.0
(Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36
Edg/80.0.361.69"
- "" [20/Mar/2020:10:56:24 +0100] "GET /favicon.ico HTTP/1.1" 403 88
Re: AW: AW: AJP Connector issue
Ok, so it looks like : - the request is effectively reaching tomcat, and that it is tomcat sending back the 403 response. - the URL is "/", so presumably it is "well-formed" etc. Furthermore, according to something you wrote below, both Apache httpd and tomcat are running on the same Linux host. This reminds me vaguely of some issue previously (and recently) discussed on the list, with some request attributes which tomcat did not like.. But I do not remember ptecisely what the issue was, and it also seems to me that this concerned an IIS front-end, not Apache httpd. Perhaps someone else on the list has a better idea. Incidentally, it also seems that you are, in httpd, proxying *all* requests to tomcat. Which raises the question of why you have a httpd front-end in the first place. (But that's a later discussion maybe, let's first see why "/" doesn't work) On 20.03.2020 11:07, Fritze, Florian wrote: Here is the additional information: The error page looks like Tomcat: HTTP Status 403 – Forbidden _ Type Status Report Beschreibung Der Server hat die Anfrage verstanden, verbietet aber eine Autorisierung. _ Apache Tomcat/8.5.53 The Apache HTTPD log file says: - "" [20/Mar/2020:10:56:24 +0100] "GET / HTTP/1.1" 403 1042 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 Edg/80.0.361.69" - "" [20/Mar/2020:10:56:24 +0100] "GET /favicon.ico HTTP/1.1" 403 885 "https://dev-fordatis.fraunhofer.de/; "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 Edg/80.0.361.69" The Tomcat says: - - [20/Mar/2020:10:56:24 +0100] "GET / HTTP/1.1" 403 630 - - [20/Mar/2020:10:56:24 +0100] "GET /favicon.ico HTTP/1.1" 403 630 The server on which all is running is: Linux 5.3.0-42-generic #34~18.04.1-Ubuntu SMP Fri Feb 28 13:42:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux There is no new entry in the Apache HTTPD error.log concering these requests. Help is appreciated Florian Fritze -- Florian Fritze M.A. Fraunhofer-Informationszentrum Raum und Bau IRB Competence Center Research Services & Open Science Nobelstr. 12, 70569 Stuttgart, Germany Telefon +49 711 970-2713 florian.fri...@irb.fraunhofer.de | www.irb.fraunhofer.de -Ursprüngliche Nachricht- Von: André Warnier (tomcat/perl) Gesendet: Freitag, 20. März 2020 10:14 An: users@tomcat.apache.org Betreff: Re: AW: AJP Connector issue On 20.03.2020 08:23, Fritze, Florian wrote: Hello Chris, thanks for the reply. Maybe I am doing something wrong, but setting secretRequired="false" does not solve my issue. Let me show you what I did and experience: I added redirectPort="8443" secretRequired="false" /> to the Tomcat configuration and the ajp connector on the Apache HTTPD side connects to 8011. When I now visit my website I got HTTP Status 403 – Forbidden And just to make diagnosis a bit quicker : does that 403 error page look like an Apache httpd page, or a tomcat page ? (they look quite differemt in style). Also, can you check both the httpd logs, and the tomcat logs for that request, and check what they say ? (compare by timestamnp and URI) Also, under what OS does your front-end httpd run ? I attached also the error page as a screenshot to this mail. This behaviour exists only sice the Ghostcat fix release (I know that this has nothing to do with security fix but probably with the release itself). Thanks in advance Florian -- Florian Fritze M.A. Fraunhofer-Informationszentrum Raum und Bau IRB Competence Center Research Services & Open Science Nobelstr. 12, 70569 Stuttgart, Germany Telefon +49 711 970-2713 florian.fri...@irb.fraunhofer.de<mailto:florian.fri...@irb.fraunhofer.de> | www.irb.fraunhofer.de<http://www.irb.fraunhofer.de> -Ursprüngliche Nachricht- Von: Christopher Schultz mailto:ch...@christopherschultz.net>> Gesendet: Donnerstag, 19. März 2020 20:14 An: users@tomcat.apache.org<mailto:users@tomcat.apache.org> Betreff: Re: AJP Connector issue -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Florian, On 3/19/20 07:43, Fritze, Florian wrote: since the Tomcat release with the Ghostcat security fix (Tomcat 8.5.51) me as an admin have the problem using the https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html module to connect the Apache HTTPD with the Tomcat running on localhost. The attribute secretRequired must be set to „true“ or „false“ with „false“ set the connection is not possible between Tomcat and Apache HTTPD. When you have set secretRequired="false", it's not possible to connect? When you tr
Re: AW: AJP Connector issue
On 20.03.2020 08:23, Fritze, Florian wrote: Hello Chris, thanks for the reply. Maybe I am doing something wrong, but setting secretRequired="false" does not solve my issue. Let me show you what I did and experience: I added to the Tomcat configuration and the ajp connector on the Apache HTTPD side connects to 8011. When I now visit my website I got HTTP Status 403 – Forbidden And just to make diagnosis a bit quicker : does that 403 error page look like an Apache httpd page, or a tomcat page ? (they look quite differemt in style). Also, can you check both the httpd logs, and the tomcat logs for that request, and check what they say ? (compare by timestamnp and URI) Also, under what OS does your front-end httpd run ? I attached also the error page as a screenshot to this mail. This behaviour exists only sice the Ghostcat fix release (I know that this has nothing to do with security fix but probably with the release itself). Thanks in advance Florian -- Florian Fritze M.A. Fraunhofer-Informationszentrum Raum und Bau IRB Competence Center Research Services & Open Science Nobelstr. 12, 70569 Stuttgart, Germany Telefon +49 711 970-2713 florian.fri...@irb.fraunhofer.de | www.irb.fraunhofer.de -Ursprüngliche Nachricht- Von: Christopher Schultz Gesendet: Donnerstag, 19. März 2020 20:14 An: users@tomcat.apache.org Betreff: Re: AJP Connector issue -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Florian, On 3/19/20 07:43, Fritze, Florian wrote: since the Tomcat release with the Ghostcat security fix (Tomcat 8.5.51) me as an admin have the problem using the https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html module to connect the Apache HTTPD with the Tomcat running on localhost. The attribute secretRequired must be set to „true“ or „false“ with „false“ set the connection is not possible between Tomcat and Apache HTTPD. When you have set secretRequired="false", it's not possible to connect? When you try to connect, what DOES happen? With „true“ the Apache development is not ready in the current version to work with the „secret“ attribute. Only the next version of Apache 2.4 supports this attribute. Correct. Support for secret= in mod_proxy_ajp was evidently never really a priority for anybody until now. So I want to use the newest Tomcat version and an AJP connector but after the Ghostcat fix release there is this attribute which does not work in my configuration. Are there any suggestions or solutions available that you can deliver me (links or documentation, etc.) secretRequired="false" should be all you need. Of course, to be truly secure, you need to make sure that not just anybody can make requests through your AJP interface. Have you secured that interface from potential evildoers? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5zxHsACgkQHPApP6U8 pFjf7Q/+Ixbc10KYI07Wb1pdzQajVtw88BcfSZ3dfam2Q9aj2IhZJD5GUTzszAGC bs6eySKEh5vqaHq+oy2ZOuv2f1xxukPQ3/XfmIEUb83G7QScwlMf0r5dth9uslcq cUgHFkpGhSQghB2yhZSzKMzF7gjRY9QI0S5EpEHTQ45CUvREWr4GRyLndkjTbu2C rhdB+8ud4iErWJe1Er0NEqOgoVL8Ceed4BGRYzoT7+lN1dRE4MFIn8ALdVzAvo4L 9ZIm+zawSkx7jUTAGDi4wHd2KrewR9kqJybovZaACx/yc6IF1Sv+DaWlTUDdabE2 qrSl45mA4EdLCeH1wfbZ62IhErbxvLahygAwgYSeMfhv02vzBbmn8bXY4yg359ln aO2AV3xNbxFrF56XatRGIJ+3/ETh2oIv0PLnJEr8xc3CcwdJ+rn8c9i84ZZLnHb6 iTl+Gx9pCUbtH0qCILzLzj7Js9yl13o9AVu3UQ9UxY9BNxkFiKKBe4YfGUev2iiB Vx1Zw6S6/ByjhUpzaSEciSYCkr+pR61iOJpCN9B3tnpv4cRgkqwPWEPgMFDtvFT9 ciwpDuN+O2YPPE0Z39tSy64Ge2QWyPkvb8hVZUEZGVMRmQ1W5LhDJhNxECklxKOh sZPFkji5aVOxj6TT5vwqQDov+FyU2pV5/HRD4fe/vr8vdKj+vec= =CYi0 -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: I wish I could forward all requests completely to another server.
On 19.03.2020 04:18, HeeGu Lee wrote:
I was tasked with writing a web application that needs to forward a http
request to each server after checking certain headers.
Of course I can use a library like apache http client to reconstruct and
send the data.
But if you think about it, this is a very unreasonable and bad way.
No, it is pretty much the only way that makes sense. Well, at least if you want to do this
with tomcat.
First : there is no code in tomcat that does any kind of "proxy/forwarding" function, nor
(to my knowledge) any plan to add such code.
See the first phrase of the tomcat on-line documentation, at
http://tomcat.apache.org/
So any such function must be implemented by a web application (servlet) running under
tomcat, and I guess that whoever asked you to create such a servlet knew this, and that's
why they asked you to do it this way.
You could also search for already-existing software which does this, for
example here :
https://cwiki.apache.org/confluence/display/tomcat/ServletProxy
or here :
https://sourceforge.net/projects/j2ep/
Suppose you need to forward a request that uploads a 100 mega file.
To forward this, once the servlet receives it as an object, the server
memory is already reduced.
Couldn't Servlet Engine check and pass only a few headers and pass it in
stream format?
See above. If you create yourself a "proxy servlet", you are allowed to do in it what you
want. As soon as tomcat receives the original request, its headers are available to your
servlet for examination, and you can start a connection to the target back-end server.
You can then read the request content body in any way you want, and send it to the target
back-end in any way you want. The only thing is, you can read ("consume") the request
body only once, so if you need to "distribute" the same request to several back-ends, you
will have to do some local buffering anyway.
Even if it is not the above example, I think the servlet may have the
ability to have it in a raw state or to return it, like the request strings
sent to telnet.
I think it would be great if this could be supported by the servlet engine
itself.
As indicated by the tomcat description, it is not really tomcat's purpose to be a reverse
proxy. There are other webservers which already contain proxying code (like Apache
httpd), and which may be a better starting point to do this.
Thank you for reading!
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP Connector issue
On 19.03.2020 12:43, Fritze, Florian wrote: Dear Tomcat users, since the Tomcat release with the Ghostcat security fix (Tomcat 8.5.51) me as an admin have the problem using the https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html module to connect the Apache HTTPD with the Tomcat running on localhost. The attribute secretRequired must be set to „true“ or „false“ with „false“ set the connection is not possible between Tomcat and Apache HTTPD. With „true“ the Apache development is not ready in the current version to work with the „secret“ attribute. Only the next version of Apache 2.4 supports this attribute. So I want to use the newest Tomcat version and an AJP connector but after the Ghostcat fix release there is this attribute which does not work in my configuration. Are there any suggestions or solutions available that you can deliver me (links or documentation, etc.) Hello. It all depends on your configuration, and how your front-end Apache httpd server(s) connect to your back-end tomcat server(s). For example : - if all your pairs of httpd server/tomcat server are running on the same host, then you do not really have a security issue, and adding a secret will not really bring any additional security - if all your pairs of httpd server/tomcat server are communicating only over an internal (presumed to be fairly safe) network, then you do have a limited security issue (limited by how "safe" your internal network really is), and a secret may help a bit in reducing this already limited security issue - if you have pairs of httpd/tomcat which communicate over a public network, then you do have a security issue, and adding a secret will help, but it is not going to make that security issue really disappear (*). But if you want to add a secret anyway, then it depends on how httpd communicates with its corresponding tomcat, and there are 2 options : - using the httpd mod_proxy_ajp module or - using the httpd mod_jk module As I understand from your message, the current mod_proxy_ajp module released with the current httpd 2.4, does not support that "secret" yet. But the currently available mod_jk module does support that option, and the current mod_jk module is compatible with any httpd 2.4 version. And, functionally, mod_proxy_ajp and mod_jk can do the same things. It is just the setup and configuration (at the httpd level) that is somewhat different between the two. (there is no difference at the tomcat level). So if you are currently using mod_proxy_ajp (**), then if you want to implement this "secret" option, you would have to change your httpd configuration, to use mod_jk instead of mod_proxy_ajp (temporarily, until the appropriate version of mod_proxy_ajp is released). (*) the secret, if correctly implemented, will block any other host than your own hosts from connecting to the tomcat AJP Connector, and thus from "abusing" your tomcats by sending them invalid or malicious requests. But it would not block someone from intercepting the traffic between your httpds and your tomcats and reading it, because the AJP protocol is not encrypted, and because there is no implementation available that makes this traffic be encrypted. (**) If you are currently using mod_proxy_ajp, then it is also likely that you are not using the option whereby httpd can do the user authentication, and then pass the authenticated user-id along to tomcat, for tomcat to use it. That means that you are already avoiding one possible security issue. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [External] Re: Starting up Tomcat 8
On 17.03.2020 21:43, Maxfield, Rebecca A wrote:
Ah, some problems are arising because, I suppose, the startup process wants to
create or touch something in ../logs and that's now all the way over in
/var/lib/tomcat8. How do I move on from here?
Try (as root) : service tomcat8 start (or restart or stop ..)
As mentioned before, the Debian package is assembled in such a way that it will function
in the same way as other "services" in the Debian environment, log in the same general
place etc..
The above command in fact runs the shell script at /etc/init.d/tomcat8.
This script sets a number of variables before calling tomcat's startup.sh, changes to the
approriate directory etc..
If you want a tomcat8 which is installed in a single directory, and which reacts in the
"canonical" way as explained on the tomcat website, then you would have to de-install the
Debian tomcat8 package, and install tomcat8 as per the tomcat website.
But that's probably, in your case, more work than necessary.
You just want to run some tomcat applications (webapps), right ?
On 3/17/20, 4:40 PM, "Maxfield, Rebecca A" wrote:
I see it now in /usr/share/tomcat8/bin, thank you! Can I just run
startup.sh from there or is that not right?
On 3/17/20, 4:37 PM, "André Warnier (tomcat/perl)" wrote:
On 17.03.2020 21:18, Maxfield, Rebecca A wrote:
> Both are Linux. The new is Debian, the old ??
On a Debian Linux system, tomcat 8 installed via the standard Debian package manager
results in some files appearing in the following directories (and
maybe others)
- /etc/tomcat8
- /usr/share/tomcat8
- /var/lib/tomcat8
- /var/log/tomcat8
- .. ?
Some of the entries in these directories are links pointing somewhere
else. It is
sometimes a bit difficult to follow. But it works, and it allows
tomcat to be managed
using the Debian usual commands for starting/stopping services,
install updates etc..
Use this command to see a full list of the directories/files used :
dpkg --listfiles tomcat8
(Note : this gives a list of directories/files initially reated or installed by the
standard Debian tomcat8 package. But it does not include anything
created/installed later
on maybe to "customise" tomcat8 on that machine).
>
> On 3/17/20, 4:03 PM, "André Warnier (tomcat/perl)"
wrote:
>
> On 17.03.2020 19:52, Maxfield, Rebecca A wrote:
> > Hello,
> >
> > I manage a project that currently runs on Tomcat 7 but is
migrating to a new server where Tomcat 8 was installed by the server admin. When I
navigate to the /var/lib/tomcat8 folder, I don’t see a ./bin folder or any startup.sh
or similar. Is this something that has changed from Tomcat 7 to Tomcat 8, or does
this imply that it was not installed completely/correctly?
> >
> What is the platform (OS) of the new server ? (and the old one)
> Maybe it was installed using a package provided by the
platform, in (eminently variable)
> other directories.
>
>
>
>
-
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
>
>
>
> › This email was sent from outside of Providence College
> › Do not click any suspicious links or open any attachments
that you are not expecting
> › Never send any sensitive or financial information (Including
passwords, social security numbers, credit card numbers, and gift cards) via email
>
>
>
> -
> 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
-
To unsubscribe, e-mail: users-unsubscr.
Re: [External] Re: Starting up Tomcat 8
On 17.03.2020 21:18, Maxfield, Rebecca A wrote: Both are Linux. The new is Debian, the old ?? On a Debian Linux system, tomcat 8 installed via the standard Debian package manager results in some files appearing in the following directories (and maybe others) - /etc/tomcat8 - /usr/share/tomcat8 - /var/lib/tomcat8 - /var/log/tomcat8 - .. ? Some of the entries in these directories are links pointing somewhere else. It is sometimes a bit difficult to follow. But it works, and it allows tomcat to be managed using the Debian usual commands for starting/stopping services, install updates etc.. Use this command to see a full list of the directories/files used : dpkg --listfiles tomcat8 (Note : this gives a list of directories/files initially reated or installed by the standard Debian tomcat8 package. But it does not include anything created/installed later on maybe to "customise" tomcat8 on that machine). On 3/17/20, 4:03 PM, "André Warnier (tomcat/perl)" wrote: On 17.03.2020 19:52, Maxfield, Rebecca A wrote: > Hello, > > I manage a project that currently runs on Tomcat 7 but is migrating to a new server where Tomcat 8 was installed by the server admin. When I navigate to the /var/lib/tomcat8 folder, I don’t see a ./bin folder or any startup.sh or similar. Is this something that has changed from Tomcat 7 to Tomcat 8, or does this imply that it was not installed completely/correctly? > What is the platform (OS) of the new server ? (and the old one) Maybe it was installed using a package provided by the platform, in (eminently variable) other directories. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org › This email was sent from outside of Providence College › Do not click any suspicious links or open any attachments that you are not expecting › Never send any sensitive or financial information (Including passwords, social security numbers, credit card numbers, and gift cards) via email - 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: Starting up Tomcat 8
On 17.03.2020 19:52, Maxfield, Rebecca A wrote: Hello, I manage a project that currently runs on Tomcat 7 but is migrating to a new server where Tomcat 8 was installed by the server admin. When I navigate to the /var/lib/tomcat8 folder, I don’t see a ./bin folder or any startup.sh or similar. Is this something that has changed from Tomcat 7 to Tomcat 8, or does this imply that it was not installed completely/correctly? What is the platform (OS) of the new server ? (and the old one) Maybe it was installed using a package provided by the platform, in (eminently variable) other directories. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: OpenId with apache and tomcat
On 13.03.2020 17:53, Stephane Passignat wrote: Hi, Actually I have Apache2 operating as proxy and authenticate layer (HTTP Form and HTTP Basic), in front of several Tomcat instances and webapps. Apache pushes the userId to tomcat through AJP. On tomcat side, the webapp has a Basic login-module in web.xml. I'm quite satisfied of the result, authentication and authorization are out of the application scope. The deployment and maintenance of application is super easy. The sensitive maintenance of authentication is made by a dedicated team... I wish to improve that adding OpenId Authentication, keeping apache as authentication layer with an openid connector, but the one I saw doesn't seems to be used a lot and is not available as precompiled for my os... Actually, mod_auth_openidc (which I have not used myself), available from (https://github.com/zmartzone/mod_auth_openidc) at least on the face of it, seems to be fairly complete, well-documented (with examples), supported, and regularly worked on. Considering your current architecture, and considering that OpenID itself (like anything to do with OAuth) is quite a nightmare in terms of readable and understandable-by-common-mortals documentation, I would think that you might save yourself a lot of time by trying it out. It seems to have its own help forums too, which may help in terms of obtaining or creating the appropriate binaries. I'm looking also at moving authentication at tomcat level with an openid Realm. It's not ideal because of the large number of applications are servers do impact and network configuration to change, Exactly, see above. I think that mod_auth_openidc would fit right in (and along) with your existing form and Basic authentication in Apache httpd. And you would not have to change anything at the Tomcat or applications level. Just make sure to properly secure your AJP connections. (see quite a few discussions on that topic in the last month, in the archives of this list) ... Does someone have experience in this architecture ? Do you have some recommendation for Apache Module or Tomcat Realm to use ? Make sure that you know exactly what *version* of OpenID you need. As far as I know, the current version is "OpenID Connect", and anything else is obsolete and even worse in terms of documentation. Thanks Stephane - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: bind Tomcat to IPv4 and IPv6 loopback, Tomcat 9.0.31
On 10.03.2020 15:44, Martin Grigorov wrote: On Tue, Mar 10, 2020 at 3:56 PM Christopher Schultz < ch...@christopherschultz.net> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 3/10/20 04:43, Martin Grigorov wrote: We can define custom address like "loopback" for which Tomcat will bind on both "127.0.0.1" and "::1" depending on the values of java.net.preferIPv4Stack and java.net.preferIPv6Addresses, but I am not sure whether it is worth it This is kind of an interesting suggestion, as would maybe supporting "all" as an alias for both 0.0.0.0 and :: together (the old default behavior, which is no longer possible with a single ). Are there any examples of these kinds of things in other products, or does everyone just manually define two separate connector-like entities? httpd just does: Listen 0.0.0.0 Listen :: Which is pretty simple. Tomcat's configuration is a lot more verbose and so repeating it is doubly so. Another option is to make "address" attribute multi valued, e.g. comma/space separated. My 2 cent : Since the changes were necessary, have been made and are presumably there to stay, and since this seems to have caused a lot of confusion with a lot of sysadmins, mainly among the ones which had a working front-end/back-end configuration, which suddenly stopped working when they made a minor version upgrade. And since even so, it seems that when the change was made, there was quite an underestimate of the side-effects and the impact this would have in the practical reality out there, should there not be a separate addition to the documentation, explaining this AJP Connector and its settings "from the ground up", starting with the fact that currently, it is basically insecure if used on an open network (and that this was not its original purpose). (At least that's my sysadmin-level understanding of what I've read here so far). And when talking about changing some Connector attributes, maybe a review should be made first, downwards as well as upwards : - downwards : ultimately a Connector represents a socket (or more than one ?), at the OS TCP/IP stack level. Some information from that OS-level socket presumably "filters up" through whatever layers there can be between it, and the container level and the Java servlets running inside that container. Is that information liklely to be used at the application level, and would proposed changes be neutral in that respect ? - upwards : it seems from the accumulated discussions here, that (for example) to implement some of the changes/improvement, users (sysadmins) may have to go as far as duplicating the whole Connector tag, to implement the "listen only on localhost" feature (but, that this depends both on the underlying OS and on the in-between layer between that OS and the Connector). And, if some application software currently "interrogates" the Connector to find out about its IP address (or the IP address of the client connected to it), what answer would it get if the "address" attribute would become multi-value ? /Could/ it even get such an answer, if the underlying socket is not one, but two ? I don't know the answer to the above questions, and I don't even know whether they really are valid questions. But again, I look at this from a sysadmin configurator point of view, without necessarily a deep understanding on the Java finery underlying all this, and I'm quite confused and worried that I could inadvertently break some user application and not really understand why. And maybe another underlying question : is it really unthinkable to have an AJP connection capable of running under SSL ? (I mean directly, not under some external setup like stunnel e.g.) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: bind Tomcat to IPv4 and IPv6 loopback, Tomcat 9.0.31
On 11.03.2020 09:30, Piyush Kumar Nayak wrote: What's the point of " ipv6v6only" attribute. The doc says : "If listening on an IPv6 address on a dual stack system, should the connector only listen on the IPv6 address? If not specified the default is false and the connector will listen on the IPv6 address and the equivalent IPv4 address if present." So if I set address to "::1" and " ipv6v6only" is left to its default, shouldn’t, the connector listen to both the addresses. I guess it depends on the precise meaning of "on a dual stack system" .. -Original Message- From: Martin Grigorov Sent: Tuesday, March 10, 2020 8:14 PM To: Tomcat Users List Subject: Re: bind Tomcat to IPv4 and IPv6 loopback, Tomcat 9.0.31 On Tue, Mar 10, 2020 at 3:56 PM Christopher Schultz < ch...@christopherschultz.net> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 3/10/20 04:43, Martin Grigorov wrote: We can define custom address like "loopback" for which Tomcat will bind on both "127.0.0.1" and "::1" depending on the values of java.net.preferIPv4Stack and java.net.preferIPv6Addresses, but I am not sure whether it is worth it This is kind of an interesting suggestion, as would maybe supporting "all" as an alias for both 0.0.0.0 and :: together (the old default behavior, which is no longer possible with a single ). Are there any examples of these kinds of things in other products, or does everyone just manually define two separate connector-like entities? httpd just does: Listen 0.0.0.0 Listen :: Which is pretty simple. Tomcat's configuration is a lot more verbose and so repeating it is doubly so. Another option is to make "address" attribute multi valued, e.g. comma/space separated. Martin - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5nnHEACgkQHPApP6U8 pFirYA/9HvjI2fX//oqTFvmgGXW/7memXkrUkMiQ3JrUhwc5KrSn4CJAamwiqzTr Lm+CACeEuiMK4qGbQ+NSpfql0k1pb8BUTX7Ut/KW1lsa8t/DY2DU0SNBw3mvnfL1 XoTsAbQgswpoxozZe11ZZyo42O2BCqTcO8Yp2X3K6DUAGvusPl00VMzpYfgsoLCv ZvxljLPRY5szRfCf7qrXOtPoByxvnKX2coQBIKJ8+MEKIo6ZApNX8OPf2HNGjvPT /OCRef/+uIXQaGIYOS8OlNxmFLEs/iGPZ2412l0rAA1hArlW4yCe7eDe3RCbiMeH FKHbqgbTRPNXWTqf3/BqEimcQj6YdXm+k019IDWGS7vhfPkiBci6qbKO9GLVjSct 4R9J++/s5CQp7zC3aM1kS5Paoho+CMevMneD0c6m4lGvM007jX4yr1z3QZxtFzqg KpcYieJgWGl0pOVw4s5YnngK1WXosb7gyjEN7ktPEE4xdeTk57shceGg1YDDRpyG n9gtwiXJf1zwUMOq0ttHNNvLdXL+y2Ud7adG5Sjg/5Y3RCP9vAQNdq+CcHS3aLGo WVfME5zcrSJlpD0arqg5ZNduYMAwgvO1GEnqfFEfEKpPXJNXAzX9YtCm0/ckFMC6 gB7xVv72Ow7kmsftA478+nPCiZTwmkVyLqVoOIr0+OSTn0tiDu0= =ewrT -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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with tomcat connector in IIS using tomcat 9.0.31
On 04.03.2020 09:30, Stephen Hames wrote: Hi Matthias, I suspect your issue is: address="::"You probably want address="0.0.0.0" or the ipv4 IP address that your tomcat instance is listening on. :: allows any on IPv6, but for IPv4 I suspect that tomcat would still be listening only on 127.0.0.1 But then, the error at the IIS level would be "connection refused", no ? Not a tomcat response with a 403 status, as seems to happen below. Or am I the confused one ? Regards, Stephen On Wed, 4 Mar 2020 at 15:20, Matthias Fechner wrote: Dear all, as tomcat version 9.0.31 has some security fixes included I tried to do an upgrade. On the IIS tomcat connector version 1.2.46 is installed. As secret I use a 32 character long alpha numeric string, I name it here token. In the workers.properties I tried to define it on the load balancer line: worker.loadbalancer.secret=token And/or on each node: worker.node1.secret=token ... worker.node2.secret=token For the tomcat configuration I defined in server.xml the following AJP connector: But it does not work. It seems that tomcat does not answer here. If I downgrade to tomcat 9.0.29 it works without any problems. I started then wireshark and had a look into the traffic coming from the IIS. From IIS is see a AJP13 connection with the following content in "Apache JServ Protocol v1.3" part in wireshark: ... Sec-Fetch-User: ?1 token INTERNAL\user Negotiate ... as the token is here included the secret configuration is maybe correct. The token is here equal to the token define on IIS-tomcat-connector and the tomcat server.xml AJP definition. Tomcat is sending back a "0:RSP:SEND HEADERS:403 403" The IIS is doing authentication is is then just sending the user to tomcat. Regarding the documentation everything seems to be configured correctly, but it does not work. Could anyone help me here, please? -- Thanks a lot Matthias - 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: issue faced in tomcat 8.5.51
On 02.03.2020 07:38, Rathore, Rajendra wrote: Hi Calder/Team, I set the below flag as false but still it will giving the same error. If you really changed that attribute in the right place, and you restarted tomcat, it is quite unlikely that you would have the same error in the log. But if you really do, could you please copy the latest Connector configuration here, and another new extract of the log showing the error ? (Just copy/paste here please, not in an attachmemnt) I am using Apache http server(with AJP worker) and tomcat configuration, Is am I missing something in configuration, please let me know? Thanks and Regards, Rajendra Rathore 9922701491 -Original Message- From: calder Sent: Friday, February 28, 2020 7:41 PM To: Tomcat Users List Subject: Re: issue faced in tomcat 8.5.51 External email from: users-return-269823-rarathore=ptc@tomcat.apache.org On Fri, Feb 28, 2020, 07:39 Rathore, Rajendra wrote: Hi Team, I am using below configuration in server.xml for tomcat but I got below exception in start up time < snip > Caused by: java.lang.IllegalArgumentException: The AJP Connector is configured with secretRequired="true" but the secret attribute is either null or "". This combination is not valid Please let me know what should I put to fix the issue, it will be very helpful for me. I am stuck because of the above issue, we are using Apache and tomcat for serving the request. Let me know if anything else required from my side. - 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: issue faced in tomcat 8.5.51
On 28.02.2020 15:11, calder wrote: On Fri, Feb 28, 2020, 07:39 Rathore, Rajendra wrote: Hi Team, I am using below configuration in server.xml for tomcat but I got below exception in start up time < snip > Caused by: java.lang.IllegalArgumentException: The AJP Connector is configured with secretRequired="true" but the secret attribute is either null or "". This combination is not valid Please let me know what should I put to fix the issue, it will be very helpful for me. Sure, here you go : look carefully at the on-line documentation, in http://tomcat.apache.org/tomcat-8.5-doc/config/ajp.html#Standard_Implementations Note, for information : these attributes and values have *changed in 8.5.51*, compared to previous tomcat revisions. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Error parsing HTTP request header
On 26.02.2020 14:30, dku...@ccilindia.co.in wrote: Dear Team, We are getting below error in catelina log while starting the tomcat. 26-Feb-2020 18:57:36.795 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 21520 ms 26-Feb-2020 18:57:38.277 INFO [http-nio-443-exec-11] org.apache.coyote.http11.AbstractHttp11Processor.process Error parsing HTTP request header Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level. java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986 at org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine(AbstractNioInputBuffer.java:283) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1017) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:684) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1524) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1480) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) Will this impact any performance of our tomcat. It is not quite clear what you mean by that question. Origin of the above : - a HTTP client sent an invalid HTTP request to your tomcat - tomcat caught this, refused the request, and warned you of it by writing a detailed error message to the logfile - tomcat also tells you that if there are any further errors of the same type, you will only see them in the logfile, if you turn the general log level of tomcat to "debug" (which produces *a lot* of messages). That is tomcat's way of saving resources, in case there are many more requests of that kind. Will this impact the performance of tomcat ? Well, of course, if your tomcat continues to receive a lot of such invalid requests all the time, that will use some of the processing time of the tomcat host, even to return an error to the client. But this has nothing to do with your tomcat per se or its configuration, it has to do with bad or malicious clients out there, which send invalid requests to your server, and it would be the same with any webserver. If you want to filter out such requests before they arrive to tomcat, you will have to put in front of tomcat some specialised filtering device which is optimised to do that kind of thing. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat
Hi. I think that we are getting complicated and confusing here. A picture is worth a thousand words, so a little ASCII graphic art may help clarifying things. browser <-(1)-> IIS + proxy <-(2)-> tomcat <-> application - connection (1) can be HTTP or HTTPS (admin choice) - connection (2) can be HTTP, HTTPS, or AJP (admin choice) To simplify, let's say that connection (1) is always HTTPS. In principle, even if connection (1) is HTTPS, IIS should be able to "proxy" the requests to Tomcat over HTTP,HTTPS, or AJP, depending on the configuration of a) IIS itself b) the proxy add-on module inside IIS A) If you want to do this : browser <-(HTTPS)-> IIS + proxy <-(AJP)-> tomcat <-> application then : - the proxy module to use in IIS is isapi_redirector - the target Connector/port in tomcat is an AJP connector - AJP is a protocol similar to HTTP/HTTPS, but it is different from them both, and it does not support encryption B) If you want to do this : browser <-(HTTPS)-> IIS + proxy <-(HTTP)-> tomcat <-> application then : - the proxy module to use in IIS is NOT isapi_redirector, it will be some other proxy module within IIS. I do not know which one or how to configure it, because I am not an IIS specialist. But it is probably a built-in module in the standard IIS. - the target Connector/port in tomcat is an HTTP Connector - HTTP is not encrypted, but it does not matter very much here, because the connection is only within the same host. C) If you want to do this : browser <-(HTTPS)-> IIS + proxy <-(HTTPS)-> tomcat <-> application then : - the proxy module to use in IIS is NOT isapi_redirector, it will be some other proxy module within IIS. same comment as for (B) - the target Connector/port in tomcat is an HTTPS Connector - HTTPS is encrypted, but this is taken care of by the proxy module on the IIS side, and the HTTPS Connector on the Tomcat side. All 3 solutions above are completely equivalent in terms of forwarding (some) requests to tomcat. But maybe something to insist on : only solution (A) above requires isapi_redirector. workers.properties is something which is /only/ used by isapi_redirector, so if you choose solutions (B) or (C), you do not need that file at all. And I do not know if it possible (but presumably it is) to configure IIS to do (B). But that is something for which in principle we cannot help you on this list, because we are not IIS specialists here. Does this make things clearer ? On 26.02.2020 00:17, Ellen Meiselman wrote: Hi Chris, Does this mean that incoming connections require SSL or aso outgoing (e.g. proxy) connections? I'm super ignorant of IIS configuration. Incoming connections require SSL or will be upgraded to SSL. So if you type in http, it will change to https. Right now because I do not have SSL set as required, I can type in http and it stays http. At that point, it starts working - I no longer get the 403 from Tomcat. My recommendation would be to take this opportunity to switch to HTTPS and dump AJP. OK, I am willing to try - so to do that, would this be the procedure? 1. Set up certificates in Tomcat (big black box for me, but I'll try to figure it out) 2. Change the worker.worker1.type to HTTPS 3. Change the worker.worker1.port to 8443 Anything else? Ellen On Tue, Feb 25, 2020 at 5:47 PM Christopher Schultz < ch...@christopherschultz.net> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ellen, Oops pressed SEND before I was done... On 2/25/20 16:47, Ellen Meiselman wrote: So it turned out that the logs were mostly set at FINE already, so Johann’s suggestion was already done. But I think I now know where the problem lies. Secure IIS request to > non-secire AJP. I don’t think this was a problem on the other servers before but the security has probably been tightened, and it just doesn’t produce an error - it just won’t allow it. I have had IIS set to require SSL Does this mean that incoming connections require SSL or aso outgoing (e.g. proxy) connections? I'm super ignorant of IIS configuration. but I turned it off to test and it actually worked all the way through to the simple.html file. so it’s some sort of policy about downgrading - which seems quite rational in retrospect. For example, this HTTP address does work. http://my.servers.domain.com/exposedApplication/simple.html I never tried it because I knew I had set SSL to required. Sometimes you make assumptions that block progress. This HTTPS address does not work - I get the 403 from tomcat. https://my.servers.domain.com/exposedApplication/simple.html So - if this makes sense to any of you, please tell me roughly what I need to do to make the AJP requests as secure as the port 80 requests. Um... I know keystores and .pem files are involved, but please give me the big picture - what port does AJP need to run on, and where do I go to find out how to
Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat
The workers.properties below look good to me at first sight. Just to eliminate something, could you try the following changes : 1) workers.properties : remove the line > worker.worker1.secret="mySecret". 2) AJP Connector in tomcat : then restart tomcat and IIS. What's happening then ? Note : this is something new in tomcat 8.5.51 compared to 8.5.50 and earlier. Before, by default, the "secret" was disabled. Since 8.5.51, by default, the secret is enabled, and you have to disable it explicitly if you don't want it (as I did above). With the settings above, we are just trying to get back to a configuration without secret, to check if that works in your case. As indicated in the documentation (http://tomcat.apache.org/tomcat-8.5-doc/config/ajp.html#Standard_Implementations) you can do that in your case, because the communication between IIS and Tomcat is fairly secure, since it happens all within the same host. On 25.02.2020 18:06, Ellen Meiselman wrote: Yes, everything is on the same server. workers.properties: # Set properties for worker1 (ajp13) worker.worker1.type=ajp13 worker.worker1.host=127.0.0.1 worker.worker1.port=8009 worker.worker1.secret="mySecret". On Tue, Feb 25, 2020 at 11:27 AM wrote: -Original Message- From: Ellen Meiselman Sent: Tuesday, February 25, 2020 10:01 AM To: Tomcat Users List Subject: Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat Hi, I've been testing, and so far, there is no change in the behavior. I am still getting the same tomcat->based 403 error. Based on what you said above... secretRequired="true" (which is the default, so it can be removed) secret="xxx" ...I removed secretRequired="true" and left secret. So the connector definition now looks like this: I'm assuming that your web-front-end is on the same server as your Tomcat instance, based on you having the address set to 127.0.0.1, correct? What do you have in your workers.properties file? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat
On 25.02.2020 17:26, jonmcalexan...@wellsfargo.com.INVALID wrote: -Original Message- From: Ellen Meiselman Sent: Tuesday, February 25, 2020 10:01 AM To: Tomcat Users List Subject: Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat Hi, I've been testing, and so far, there is no change in the behavior. I am still getting the same tomcat->based 403 error. Based on what you said above... secretRequired="true" (which is the default, so it can be removed) secret="xxx" ...I removed secretRequired="true" and left secret. So the connector definition now looks like this: I'm assuming that your web-front-end is on the same server as your Tomcat instance, based on you having the address set to 127.0.0.1, correct? What do you have in your workers.properties file? addendum : .. on the IIS side of things. There should be the same "secret" there. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat
On 24.02.2020 22:04, Christopher Schultz wrote: With 8.5.51, requiredSecret is renamed "secret" but "requiredSecret" is still an alias of the same configuration property. If #2 happens after #1 above, then your actual secret will be the literal string "true" (oops). We apologize for this confusion. We are trying to clarify things and make them more secure. Nobody is saying that the new configuration and attributes are not better, from a security point of view. The latest on-line documentation, when taken in isolation, is also pretty clear and understandable. So people installing tomcat for the first time should have no problem. But I think that quite a few recent posts show that these changes could have been made a bit more visible for people who have running tomcats, and are just updating from one minor version to the next minor version. Even the on-line documentation for the Connector, shows the current attributes and defaults, but without any mention that they have just changed compared to the previous minor version. That has apparently caught a lot of people unaware. Now how to make this more noticeable, without also alerting the bad guys about the pre-existing vulnerabilities, is probably not so easy.. How about adding a note on top of the migration guide pages, saying : "If you are just updating from 8.5.50 or lower, to 8.5.51 or higher, you *really* should look at the AJP Connector attributes again". - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Novice Tomcat Admin Question - Filtering log output
On 21.02.2020 18:49, Darryl Philip Baker wrote: On 2/21/20, 11:36 AM, "Christopher Schultz" wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Darryl, On 2/21/20 12:15, Darryl Philip Baker wrote: > I have taken over the administration of several Tomcat instances. > A number of these are load balanced using an F5 appliance. The > org.apache.catalina.values.AccessLogValve log file is filled with > the F5 polls to see if the application is alive. Under almost all > circumstances these are useless, I would like to stop logging just > these requests. Dumb question: why bother removing them? Not so dumb a question, I have 2 reasons. First when looking at the raw file on the server these poles from the load balancers make it hard to find the useful entries. The second reason is we use Splunk as a log aggregator. In Splunk it is easy to filter these out when looking at the log but having all these almost useless messages significantly adds to the activity of the Splunk forwarder on these systems. Apart from everything else (I had a few dumb questions/remarks of my own), See : http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Access_Log_Valve attribute : conditionUnless So you could use this, along with a Filter which applies only to requests with URI "/MySite/isAlive.jsp" and sets an attribute "junk" for these; and bingo! they would not be logged anymore. This page even seems to show how you could do that without a Filter, directly in your own "isAlive.jsp" : https://www.roseindia.net/jsp/requestsetattribute.shtml (No guarantee though, I'm not really the expert here) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FW: Apache Tomcat versions and proof of support
Hi. Maybe you could start by looking at this page : http://tomcat.apache.org/index.html and this one : http://tomcat.apache.org/whichversion.html (including the comments after the table) Tomcat is open-source (and free) software, developed, distributed and supported by volunteers. Depending on which operating system platform you are using, the version of tomcat that you are using may be supported by the OS vendor. There are also commercial organisations which offer (paying) support for tomcat. Otherwise, tomcat support is essentially via this very list, which is also manned by volunteers. There is also extensive documentation on-line, even for older versions of tomcat. See : http://tomcat.apache.org/findhelp.html So in terms of "proof of support", what are you expecting exactly ? I don't think that there is any other formal "proof document", other than the pages mentioned above. In practical terms, examining this list and its archives (see http://tomcat.apache.org/lists.html) should convince anyone that the actual support of tomcat is pretty good, responsive and consistent over the years. And if I am allowed a personal and subjective comment, I would add that it certainly beats the support available for a lot of commercial products out there. On 21.02.2020 17:27, Hallstrom, Robert J. CTR wrote: Good morning, I wanted to follow up on my previous email regarding proof of support for earlier versions. Please advise if anyone could ASAP. Regards, Robert Hallstrom Configuration Management Specialist Imagine One Technology & Management, Ltd. 2510 Walmer Ave. Ste. A, Norfolk, VA 23513 Phone:(757)852-6941 Cell: (757) 663-8543 Email: robert.hallst...@imagine-one.com<mailto:robert.hallst...@imagine-one.com> From: Hallstrom, Robert J. CTR Sent: Tuesday, January 21, 2020 10:24 AM To: 'users@tomcat.apache.org' Cc: Hardemon, David (CTR) ; Powell, Tramphis W. (CTR) Subject: Apache Tomcat Good morning, I need documentation to prove that version 8.5.16 is still supported. We use it in supporting a legacy application and need that in order to keep doing so. Do you know where I can find a list of what versions are still supported? Regards, Robert Hallstrom Configuration Management Specialist Imagine One Technology & Management, Ltd. 2510 Walmer Ave. Ste. A, Norfolk, VA 23513 Phone:(757)852-6941 Cell: (757) 663-8543 Email: robert.hallst...@imagine-one.com<mailto:robert.hallst...@imagine-one.com> - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
On 13.02.2020 11:05, logo wrote: Am 2020-02-13 10:57, schrieb Olivier Jaquemet: On 13/02/2020 10:32, Rémy Maucherat wrote: On Thu, Feb 13, 2020 at 9:33 AM Olivier Jaquemet wrote: On 13/02/2020 01:02, Stefan Mayr wrote: - AJP defaults changed to listen the loopback address, require a secret and to be disabled in the sample server.xml [snip] Am I correct ? Why such a change ? Why no bugzilla issue for proper tracking and context ? What are your recommendations regarding AJP connector configuration ? It is obviously best to keep default configurations as stable as possible. But sometimes things have to change ... As a result, you'll indeed need to adjust your server.xml according to your deployment and AJP usage. Thank you Rémy for taking the time to answer. I understand the need to introduce a "secured by default" AJP configuration. However, I question one choice that was made for this change : the default behavior of the AJP connector to listen only on the loopback address. +1 This is the change which is, to me, the most questionable one. Because to my understanding, any architecture in which a remote Apache HTTPD is being used will require a *specific IP address of the current host* to be specified in the address attribute of the AJP connector. A specific IP address means that the server.xml is no longer agnostic to the platfom it is being hosted on. Prior to this, a server.xml file could be configured in such way that it would never contain any hard coded value related to the current host. With this change it is no longer possible. (unless I'm missing something). For large deployment configuration, this does seems a bit problematic. Do you understand my concern ? Is there any way to address this ? That's really difficult. Specifically in container environments where the container is started dynamically and the ip address shifts frequently. Access is done through dns or labels. (The secret attribute is less of a problem, because as stated in the documentation there is an alternative : secretRequired can be set fo false "when the Connector is used on a trusted network".) Make that such a breaking change in a minor maintenance update is quite touchy. I have never seen such drastic change in my usage history of Tomcat. For info, there is also another thread entitled "Re: Tomcat 8.5.51 fails", which seems relevant to this discussion. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.51 fails
On 13.02.2020 10:36, kohm...@iris.eonet.ne.jp wrote: On 2020/02/13 18:25, André Warnier (tomcat/perl) wrote: Check in the file (tomcat_dir)/conf/server.xml, the Connector : The setting is the same as mine. I have use server.xml used in 8.5.50. In case of 8.5.50, I have no problem. Please notice, I have been using Tomcat for 5 years with updates. Why this time? Yes, you are right, and I am sorry for my previous short answer. (I thought that you were a "newbie" installing tomcat 8.5 for the firdst time, and that you had just not configured the Connector correctly.) But Remy's answer, and the other thread "Re: [ANN] Apache Tomcat 9.0.31 available" seems to indicate that this was due to a *change* in behaviour between 8.5.50 and 8.5.51. In any case, it seems that for now, you will have to modify the AJP Connector configuration in server.xml, to make it work with 8.5.51 and above, and add an explicit secretRequired="false" attribute. And maybe also an explicit listening address.. It looks like these changes are documented here : http://tomcat.apache.org/tomcat-8.5-doc/changelog.html --> Coyote Update: Disable (comment out in server.xml) the AJP/1.3 connector by default. (markt) Update: Change the default bind address for the AJP/1.3 connector to be the loopback address. (markt) Add: Rename the requiredSecret attribute of the AJP/1.3 Connector to secret and add a new attribute secretRequired that defaults to true. When secretRequired is true the AJP/1.3 Connector will not start unless the secret attribute is configured to a non-null, non-zero length String. (markt) I think that the first change above is ok, because it only affects the distribution of newly-downloaded server.xml files. But the other two also impact existing installations just being updated, and in a way that is not very clearly indicated in the on-line documentation. That looks a bit more iffy.. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.51 fails
On 13.02.2020 10:13, kohmoto wrote: Hi, I have install Tomcat 8.5.51 today and found something wrong. I have been using tomcat for last 5 years and never met this kind of problem. It would be appreciated if I could be advised. Thank you. System: CentOS 7.7.1908 httpd 2.4.41 (community version) httpd.conf: (LoadModule proxy_ajp_module lib64/httpd/modules/mod_proxy_ajp.so) httpd-proxy.conf: ProxyPass ajp://localhost:8009/manager/ tomcat 8.5.* error log--- 13-Feb-2020 17:13:12.523 重大 [main] org.apache.catalina.core.StandardService.startInternal Failed to start connector [Connector[AJP/1.3-8009]] org.apache.catalina.LifecycleException: プロトコルハンドラの起動に失敗しました ( 'fail to start protocolhandler' in English ) at org.apache.catalina.connector.Connector.startInternal(Connector.java:1057) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:440) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:766) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.startup.Catalina.start(Catalina.java:688) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474) Caused by: java.lang.IllegalArgumentException: The AJP Connector is configured with secretRequired="true" but the secret attribute is either null or "". This combination is not valid. at org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.java:274) at org.apache.catalina.connector.Connector.startInternal(Connector.java:1055) ... 12 more Hi. The log message above : Caused by: java.lang.IllegalArgumentException: The AJP Connector is configured with secretRequired="true" but the secret attribute is either null or "". This combination is not valid. seems pretty clear. Check in the file (tomcat_dir)/conf/server.xml, the Connector : and the associated on-line documentation : http://tomcat.apache.org/tomcat-8.5-doc/config/ajp.html search for "secretRequired". - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP error response payload
Hi Saurav, On 08.02.20 07:47, Saurav Sarkar wrote: > Through tomcat access valve i can view the HTTP request url ,response code > etc. > > But i can not view the error response being sent in the form of JSON > payload. > > Is their any valve/filter/ any other setting on tomcat level which can > enable this or applications (server and clients) themselves have to log it. Logging HTTP request or response bodies in access logs (or similar) is not common as this can be anything from a simple (short) string to long binary data. If you need specific errors, I would suggest to log it in your application specific logs (you can add session id "%S" or other identifiers to your access log for easier mapping, see https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Access_Log_Valve for details). If you do not have a chance to add this to your logs you can implement a ServletFilter which logs the body of requests for certain requests. hth, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] distinction between resource charset and format octet decoding
On 06.02.2020 14:44, Mark Thomas wrote: On 06/02/2020 13:39, Garret Wilson wrote: On 2/6/2020 10:36 AM, Mark Thomas wrote: … Whether Tomcat should ship with this setting present in conf/web.xml by default is something that should probably be discussed for Tomcat 10. Given the current state of the web, there is a reasonable case for doing so. I'll add that to the TOMCAT-NEXT discussion list. Is this still on the list for discussion for Tomcat 10? No, because it has already been implemented for Tomcat 10 and is in the milestone release currently being voted on. Waitasec. I'm not used to good news, so I want to make sure I understand what you're saying. Are you saying that the proposed Tomcat 10 implementation already interprets encoded octets in web form submissions using UTF-8 by default?!! :O As of Tomcat 10, conf/web.xml contains the following: UTF-8 UTF-8 That *should* have the effect you are looking for but I confess I haven't tested it in any great detail. As I am sure many people (Christopher included) would agree, the real solution would be for browsers and other HTTP clients to indicate clearly in the request, the charset/encoding of each text parameter that they are sending. There are even HTTP headers already defined for that. (Nowadays the default could be Unicode/UTF-8). The problem is that browsers and other agents don't do that, although they undoubtedly always know themselves, and although it would solve a series of issues that have literally been there forever at the server and application level (*). I have often wondered if/why the Apache Foundation does not pack enough influence over the HTTP/HTML specifications process and over browser producers, to achieve that. (And if not the Apache Foundation, then who ?) (*) My own guess is that this basic thing (or lack of it) has cost over the years many thousands of lines of unnecessary code and many thousands of unproductive developer hours. As a tiny example, just consider the above web.xml parameters, and how much time in total was dedicated to their definition and implementation.. Never mind all the previous related filters and valves and their discussions on this list. And that's only for Tomcat. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat9, JSP, CSS and JS not loading in Firefox
On 22.01.2020 10:26, Lmhelp1 wrote: Hello Chris and all, Sorry for my late answer. Thank you for the link you suggested me to read. Adding the element: UTF-8 to "web.xml" solved my problem. Glad to hear that. From an absolute point of view, this is of course again a "patch". But as Chris pointed out before, it is unfortunately an unavoidable one, due to the fact that the browsers lamentably fail to always indicate the character set and encoding that they are using for sending text data to the server. [RANT:] (Although they know, and although the specifications provide them with an easy way to do that. Why that is so is anyone's guess, but the economic losses due to that over the years must be staggering). (probably close to the cost of allowing spaces in directories and files names) On 17/01/2020 3:17 PM, Christopher Schultz wrote: Your filter changes the encoding of both the request AND the response. It's likely that fixing the request-encoding was necessary, while changing the response-encoding was not. The problem is: 1. The official RFC-defined default character encoding for HTTP is ISO-8859-1. 2. The browser default appears to be unpredictable, but often UTF-8. 3. The browsers have all agreed not to tell the server what characted encoding is actually being used. It's fun. It's a very simply-solved problem: the browser should just advertise the character encoding and everything would be great. Sadly, n o. I would encourage you to read this page in its entirety: https://cwiki.apache.org/confluence/display/TOMCAT/Character+Encoding - -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
Re: Tomcat9, JSP, CSS and JS not loading in Firefox
On 17.01.2020 04:15, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Léa,
On 1/16/20 9:33 AM, Lmhelp1 wrote:
Hello,
Thank you for your answers.
I changed /* to
*.jsp I also un-commented the line:
servletResponse.setContentType("text/html; charset=" +
Finals.S_CHARSET);
It looks like the problem is solved.
[snip]
Shall I leave *.jsp as it is, or can
you suggest another pattern?
There is a better solution:
1. Delete the files and removed references to it in web.xml
2. Edit your JSP files and properly set the content-type and encoding
in the @page directive at the top of the file.
I believe Chris had a bit too much - or too little - coffee when he wrote the above, and
that he meant :
1. Delete the *filter* and remove all references to it in web.xml
2. ...
The point is : if your application is well-written and follows the standards, you should
not normally need this Encoding filter, and everything should "just work". This filter is
probably a left-over "patch" from either an older (and incorrect) application version, or
some older version of Tomcat.
That is why I first recommended that you remove the whole filter section from your
web.xml, and check what happens. Display some pages which /should/ contain some text in
non-English languages (meaning with "diacritics" like è, é, à, ü, ö, ..) and if they
display correctly, there is nothing else to do.
Only if you /do/ get a wrong display of some of that data, then you should come back here,
and try to describe what is wrong. And we could then help you find the root cause.
That would be better than trying to apply a patch over a patch over a patch..
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Antwort: Tomcat9, JSP, CSS and JS not loading in Firefox
On 16.01.2020 10:36, Lmhelp1 wrote:
Hello,
Thank you for your answer.
Indeed, I have such a filter:
In "web.xml":
EncodingFilter
com.[...].EncodingFilter
requestEncoding
UTF-8
EncodingFilter
/*
The "doFilter()" method of the "EncodingFilter" class which implements "Filter":
public void doFilter(ServletRequest servletRequest,
ServletResponse servletResponse,
FilterChain filterChain)
throws IOException, ServletException
{
// Respect the client-specified character encoding
// (see HTTP specification section 3.4.1)
if(servletRequest.getCharacterEncoding() == null)
{
servletRequest.setCharacterEncoding(ms_encoding);
}
// Set the default response content type and encoding
servletResponse.setContentType("text/html; charset=" +
Finals.S_CHARSET);
servletResponse.setCharacterEncoding(Finals.S_CHARSET);
filterChain.doFilter(servletRequest, servletResponse);
}
Commenting the line:
servletResponse.setContentType("text/html; charset=" + Finals.S_CHARSET);
doesn't solve the problem.
I still get the error:
The stylesheet http ://localhost/fr/css/fo.css was not loaded because itsMIME type,
“text/html”, is not “text/css”.
----
Also note :
https://tomcat.apache.org/tomcat-9.0-doc/servletapi/javax/servlet/ServletResponse.html#setCharacterEncoding-java.lang.String-
says :
"...calling this method with the String of UTF-8 is equivalent with calling setContentType
with the String of text/html; charset=UTF-8."
So, in the above, if you have just commented-out the line :
servletResponse.setContentType("text/html; charset=" +
Finals.S_CHARSET);
but you left the following line unchanged
servletResponse.setCharacterEncoding(Finals.S_CHARSET);
then executing this line is equivalent to setting the content type to
"text/html".
And this looks suspiciously like the error you are getting..
As another way of avoiding that problem, you may also want to change in web.xml
:
> /*
by something that applies *only* to HTML responses.
Best regards,
--
Léa
On 15/01/2020 5:09 PM, Niall Fitzpatrick wrote:
Hi Lea,
I experienced this problem not so long ago when we upgraded our Tomcat to a later
version of 9. Basically we had a filter applied to requests which was supposed to set
the encoding of the response to be UTF-8. However, it was also setting the content type
to text/html.
Previous to the Tomcat upgrade it wasn't an issue. I found that in one of the Tomcat
updates (can't remember which one) the logic of the default servlet was altered such
that if the content type has already been set in the response it can't be set again
further down stream. So my resolution was to remove the line that set the content type
in our filter.
Something to check anyway as it took me some time to figure out what was
happening.
Niall
-
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: Antwort: Tomcat9, JSP, CSS and JS not loading in Firefox
On 16.01.2020 10:36, Lmhelp1 wrote: Hello, Thank you for your answer. Indeed, I have such a filter: In "web.xml": [...] What happens if you disable that filter entirely, in web.xml ? (comment-out the whole section above, as shown) Note : ignore any character encoding errors that you may get in the response, for now. (probably shown as ). The point is to verify if it is really that filter which causes the problem with the CSS files. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Expected behavior of calling javax.servlet.ServletRequest#getInputStream after javax.servlet.http.HttpServletRequest#getPart
On 10.12.2019 15:31, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Behrang, On 12/8/19 05:18, Behrang Saeedzadeh wrote: If I call javax.servlet.ServletRequest#getInputStream after having called javax.servlet.http.HttpServletRequest#getPart, even without performing any operations on the given part, I am getting an empty stream (0-bytes). Is this in compliance with the spec? What does the servlet spec say about that situation? A bit in defense of the OP, I have to say that the Servlet Spec (4.0 final) does not seem extremely clear on that subject. In section "3.1.1 When Parameters Are Available", it /does/ say this : "If the conditions are met, post form data will no longer be available for reading directly from the request object’s input stream." But among those conditions that have to be met (just above that quote) is "4. The servlet has made an initial call of any of the "getParameter family" of methods on the request object." (So there, it talks about "the getParameter family", not the "getPart" ones). It only talks about the "getPart" methods in the next section "3.2 File upload", and in that section, all it says about the input stream is : "If the servlet container does not provide the multi-part/form-data processing, the data will be available through the HttpServletReuqest.getInputStream." So the way I read this, is that there is nothing that explicitly says that the InputStream is no longer available if you have called "getPart". (It is also in fact not very clear about what happens to the parameters, when the content-type of the Request is "multipart/form-data", which is only mentioned in section 3.2.) On the other hand, http://tomcat.apache.org/tomcat-9.0-doc/servletapi/index.html --> Interface HttpServletRequest says : Part getPart(java.lang.String name) throws java.io.IOException, ServletException Gets the named Part or null if the Part does not exist. *Triggers upload of all Parts*. (emphasis mine) which /may/ be taken to mean (and probably does) that it consumes the whole InputStream. But again, this may be lacking some overall clarity. In any case, the OP's question is not really unwarranted, unless there is some other explanation somewhere which I have missed. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Bouncing Tomcat from HTTPD?
On 05.12.2019 19:56, Jerry Malcolm wrote: I was stuck in traffic an hour from the office when I got a text that one of my sites had gone down. If I'd been in the office, I'd try bouncing TC first just to try to get the client back online, then dig into the logs to figure out what happened. But while driving on the freeway, there's no way to access ssh into the server and key in the command to restart tomcat. httpd was working fine. It would have been nice to bring up a non-tomcat web page on my phone and press a button to cause the tomcat service to restart. I know I could probably write something in php or perl or something. But I don't want to reinvent the wheel. Are there some packages available that already do something like this? Sorry, but since using one's mobile phone while driving is known as dangerous and even against the law in many places, the security-conscious and law-abiding Tomcat support team does not think it can answer the question as phrased above. Now if you were to rephrase it, leaving off the "while driving" bit, we might tell you that some such things probably exist already, but that you would have to look at admin-like utilities or packages belonging to your OS distribution, as there is nothing in Tomcat itself which provides such a capability.(*) We may also then warn you about the security aspect of such things, because one would probably not want to allow the general public to restart one's Tomcat server through an open webpage. (*) (If there was such a capability, there would also be the interesting philosophical question of how to use it, if the Tomcat server is down). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Double Slash Support in Tomcat 9.0.27
Hi Christopher. I believe that yours is a really good explanation of why Tomcat collapses consecutive slashes in URLs. It's certainly worth a FAQ article, in case the question ever pops up again. It maybe even be worth a note somewhere in the main documentation, such as where it explains how Tomcat actually maps URLs to webapps. Except that I can't locate the documentation which specifically explains this.. Maybe this is because Tomcat normally refers to the Servlet Spec for this ? The closest I find is here : http://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Naming Maybe inserting a note to the effect of 'Note: before any of the mapping below takes place, Tomcat collapses any consecutive "/" characters in the path portion of the URL to a single "/". The complete explanation is here : --> FAQ article" ' On 05.12.2019 17:13, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 12/5/19 04:55, André Warnier (tomcat/perl) wrote: Christopher, I believe that the problem of the OP is that either this filter or the application, *relies* on the fact that Tomcat would NOT collapse multiple consecutive slashes in the URL, to a single slash. That (the non-collapsing) seems to have been the case in some previous versions of Tomcat, and has apparently been changed in more recent versions of Tomcat (and probably rightly so, to adhere more strictly to the specs). Actually, it's somewhat in *violation* of the specs. But it's a generally-accepted violation because it allows security rules to actually remain sane. If you want to protect "/foo/bar.html" which maps to a file on the disk, you'll find that the filesystem collapses slashes and will load that same file regardless of how many extra slashes you put in there. "/foobar.html" is going to give you the same result. The same is true for multiple levels like "/foo/bar/bar.html". If you want to protect all files in "/foo/bar" it's not practical to add protections for "/foo/bar/" and "/foo//bar/" and "/foo///bar/" and ... you see where I'm going with this. So the server decides that slash-collapsing will allow security constraints to be more practically applied. What if we get super-spec-compliant and allow those extra slashes? Well, you'd have to get really (and, IMHO, /overly/) strict about how those slashes are treated. In Java, you'd have to do something like this : String path = ... // file-path from request String docRoot = ... // docroot base, absolute File file = new File(docRoot, path); if(!file.exists()) // return 404 if(!path.equals(file.getAbsolutePath().substring(docRoot.length())) // return 404 That last check will check to make sure that the path requested by the client *exactly equals* that of the path on the disk. That means that multiple-slashes are essentially forbidden when requesting disk-files. (It gets more fun when you are requesting a directory which has an "index file" like index.html and you have to decide whether or not it's okay to load that file automatically, even though the client didn't specifically request it.) So now we are spec-compliant. Yay! Except that all those sloppy webmasters links no longer work because they do all kinds of weird URL manipulations that don't always result in a perfectly-clean URL. So we've achieved spec-compliance and inconvenienced users. Did we really achieve anything? Those multi-slash URLs were never going to work. It is really a big deal to just ... let them work? So we collapse slashes and everything is fine. Nobody is really going to complain if /foo//bar.html and /foo/bar.html both work instead of one of them returning 404. What about resource that are *not* on a disk? Like servlets and stuff like that? Well, the servlet spec allows us to map to URL patterns of various types. Some are exact, others prefixes, etc. We can also define security constraints with the same kind of url-pattern basis. Generally, those things should agree. What happens when you introduce multiple-slashes in there? Well, nobody is ever going to map a bunch of additional slashes to make their servlets work properly. So we are back to the same problem as the on-disk-file: the multiple-slashes are essentially forbidden if we want to be super-spec-compliant. So we relax a little and take the practical approach: collapse slashes and move on with our lives. This has the added benefit of making security constraints more consistent, and fewer mistakes. And encouraging fewer security mistakes is a Good Thing. And the collapsing of multiple consecutive slashes in the URL, is probably done at such an early stage in the request processing, that it is not easy to do something to turn it off (which may or may not be spec-compliant anyway). Turning it off would be a giant mess. And yes, it needs to be doe quite early because Tomca
Re: Double Slash Support in Tomcat 9.0.27
Christopher, I believe that the problem of the OP is that either this filter or the application, *relies* on the fact that Tomcat would NOT collapse multiple consecutive slashes in the URL, to a single slash. That (the non-collapsing) seems to have been the case in some previous versions of Tomcat, and has apparently been changed in more recent versions of Tomcat (and probably rightly so, to adhere more strictly to the specs). And the collapsing of multiple consecutive slashes in the URL, is probably done at such an early stage in the request processing, that it is not easy to do something to turn it off (which may or may not be spec-compliant anyway). I did not look up the HTTP specs to find where this collapsing of slashes is specified, but I found this in the Apache httpd documentation, which would seem to suggest that consecutive slashes are not necessarily invalid, and may even *mean* something : http://httpd.apache.org/docs/2.4/mod/core.html#location (see : Note about "/") Ok, then I got curious and did have a quick look at RFCs 7230 and 7231, and they are mute about consecutive slashes. RFC2396 on the other hand does not seem to forbid consecutive slashes, and as I understand it, they are even "significant", as they seem to delimit a path element (which just happens to be empty). https://tools.ietf.org/html/rfc3986#section-3.3 does not seem to forbid consecutive slashes either. But I would suppose that if the Tomcat developers decided to collapse multiple consecutive slashes, they must have had a reason. On 04.12.2019 15:18, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kushagra, On 12/4/19 06:32, Kushagra Bindal wrote: I am not saying that this is a tomcat issue, I am just asking if there is a way by which we can handle this. As maybe in later version of 8.5.24 Tomcat has take some action to handle such conditions. I still don't really see the problem. Your responses have included tiny bits of information separately and not everything all at once. If you have a defined and mapped to a URL pattern, it should work and not give you a 404. Try this with the examples application: http://localhost:8080/examples/servlets/servlet/HelloWorldExample It will respond no matter how any slashes you put in various places: http://localhost:8080/examples/servlets/servlet//HelloWorldExample http://localhost:8080/examples/servlets//servlet//HelloWorldExample http://localhost:8080/examples/servlets/servlet//HelloWorldExample There are no 404 errors. Are you sure your application has deployed correctly? - -chris On Wed, Dec 4, 2019 at 4:53 PM Mark Thomas wrote: On 04/12/2019 05:16, Kushagra Bindal wrote: Hi Mark/Manna/Chris, Do we have any way out to handle this type of behavior? All the evidence so far points to an application issue, not a Tomcat issue. If you are able to create a simple test case that demonstrates a Tomcat issue we can take a look. Mark On Tue, Dec 3, 2019 at 5:46 AM Kushagra Bindal < bindal.kusha...@gmail.com> wrote: Chris, If you will check in my early email then you will find that with // it is throwing 404. But as soon as I removed it manually then it starts working properly and all these url were working fine in 8.5.24 version. On Tue, Dec 3, 2019, 1:21 AM Christopher Schultz < ch...@christopherschultz.net> wrote: Kushagra, On 12/2/19 11:29, Kushagra Bindal wrote: I think it should be. DanglingSessionInvalidateFilter DanglingSessionInvalidateFilter com.SessionInvalidateFilter DanglingSessionInvalidateFilter /restcall/* Here in below URL: "http://backend_tomcat:8080/sdm/restcall/v1/platform//healthChec k" sdm will be the context path. But in another example that I shared in my last email, one use case http://backend_tomcat:8080//sdm/restcall)(.*)/file_uploads my context path itself contains //. So, please suggest a viable solution which we can try to solve this problem. :) Thanks in advance for your help & support in resolving this issue. All of these slashes really should be collapsed into a single slash before processing. I don't see an issue. If the client requests: http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck then the filter/servlet at /sdm/restcall/* will respond. If the client requests: http://backend_tomcat:8080//sdm/restcall/foo/file_uploads Then the filter/servlet at /sdm/restcall/* will respond. It doesn't really matter how many extra slashes the client adds... they should all be collapsed by the server and your application should not have to make arrangements to handle them, add them back, or worry about whether they are there or not. -chris On Mon, Dec 2, 2019 at 9:00 PM Mark Thomas wrote: On 02/12/2019 10:59, Kushagra Bindal wrote: Hi Mark, These are Rest Endpoints, and so will be processed through Filter. That is unusual. Do, you think Servlet mapping will play a
[OT] Re: FW: tomcat creating new ssl session id for same session
On 29.11.2019 06:59, rekha...@dell.com wrote: Highly Restricted - Confidential ... Then maybe a public list, which is also archived for years in various places, is not the best communication channel ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat service app
On 30.10.2019 22:03, Mark Thomas wrote: On October 30, 2019 7:41:07 PM UTC, George Stanchev wrote: My question about the source stays, but I guess I should've RTFM where it states that the wrapper uses # *or* ; as separator and if you want to embed those character you need to wrap them in single quotes... From: George Stanchev Sent: Wednesday, October 30, 2019 1:33 PM To: Tomcat Users List Subject: tomcat service app I am trying to troubleshoot an issue where when I call tomcat8.exe with following parameters it writes [2] to the registry (newline where the semicolon was) and I am having trouble locating the source code repository for the Windows service app. Can someone point me to it? (Or tell me what I've done wrong with that property value) George [1] tomcat.exe //US//SbmTomcat --Jvm "C:\Program Files\myapp\jre1.8\bin\server\jvm.dll" --JvmOptions "...#-Djava.ext.dirs=C:\Program Files\myapp\jre1.8\lib\ext;C:\Program Files\myapp\jre1.8\lib\ext.fips#..." [2] ... -D Djava.ext.dirs=C:\Program Files\myapp\jre1.8\lib\ext C:\Program Files\myapp\jre1.8\lib\ext.fips It is Apache Commons Daemon. Source here: https://github.com/apache/commons-daemon Mark And maybe this helps, as a general explanation : https://cwiki.apache.org/confluence/display/TOMCAT/Windows#Windows-Q11 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot add dependency job for unit systemd-console-setup.service
On 20.10.2019 10:07, Emefile Francis Nwajie wrote: Hello All, Top of the day to you. I have a VPS with CentOs 7. I am trying to start-up Tomcat 9.0.27 using "systemctl start tomcat". And I got the error message - "Cannot add dependency job for unit systemd-console-setup.service". I am wondering if there is something I have to setup in my CentOS 7 VPS or if it is an issue with Apache Tomcat 9. Searching Google for "Cannot add dependency job for unit systemd-console-setup.service" gives plenty of results (including you own message to this list), most of which seem to refer to some systemd issue in various Linux distributions. So, on the face of it, it does not look like a tomcat issue. Maybe an issue of the particular packaged distribution of tomcat that you are using with CentOS 7 ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 8 post call lost in process
Hi. It is unfortunately a bit difficult to make sense of the description and information that you provide below. But one thing is quite certain : By the time tomcat (if I understand correctly, the one that you call the "slave") writes a line to its access log, with a result code "200 OK", it means that this tomcat not only *received* the request, but also that it *processed* this request, succesfully, *and* sent the response back (also succesfully) to whoever sent this request to it. It is difficult to read the tcpdump log that you provide below, but it looks like it also shows that for each POST from the "master" to the "slave", there is a HTTP response with code 200 OK, from the "slave" to the "master". Why do you think that these responses are being "lost" ? Maybe you should have a closer look at the application on the "master" side, to see why it does not seem to catch the slave responses ? Also, take into account that if the /application/ on the "master" side makes a connection to the slave, this is not tomcat code, it is the application code, and tomcat itself (the master) knows nothing about this. So there is little that we can do to help you. On 18.10.2019 15:57, Saurabh Barthwal wrote: Hi Team, I am facing one unusual problem with tomcat. I am using 2 tomcat server for master and slave architecture. when master send's HTTP request(POST) to slave if slave is taking more then 1 hr then the slave tomcat is not responding back but in slave tomcat's localhost_access.log is showing request as 200 ok but that is not revived by master tomcat server there is no time out (we are using infinite connection time out ) send I checked master's tcp connection after 1 hr it is good(ESTABLISHED). So I tried to capture all requests at slave server's tcp port by tcpdump but the request is lost after tomcat logs into localhost_access.log(as a success) but not went to tcp port. No idea where the request lost. Details and logs : tomcat 8.0 *localhost_access_log.txt of slave* xx.xx.xx.xx - - [18/Oct/2019:08:51:07 -0400] "POST /path/process5 HTTP/1.1" 200 2737 *tcpdump output at slave * reading from file /tmp/http18103.log, link-type EN10MB (Ethernet) 07:36:32.960401 IP xx.xx.xx.xx.52978 > slaveServer.webcache: Flags [P.], seq 282516513:282516889, ack 3687166207, win 229, options [nop,nop,TS val 3093985757 ecr 3091920822], length 376: HTTP: POST /path/process1 HTTP/1.1 07:36:34.783281 IP slaveServer.webcache > xx.xx.xx.xx.52978: Flags [.], seq 1:2577, ack 2838, win 280, options [nop,nop,TS val 3091922673 ecr 3093985759], length 2576: HTTP: HTTP/1.1 200 07:36:45.022982 IP xx.xx.xx.xx.53120 > slaveServer.webcache: Flags [P.], seq 1539707126:1539707502, ack 2187000281, win 229, options [nop,nop,TS val 3093997820 ecr 3091932884], length 376: HTTP: POST /path/process2 HTTP/1.1 07:36:56.300518 IP slaveServer.webcache > xx.xx.xx.xx.53120: Flags [.], seq 1:2577, ack 3329, win 300, options [nop,nop,TS val 3091944190 ecr 3093997820], length 2576: HTTP: HTTP/1.1 200 07:36:56.512553 IP xx.xx.xx.xx.53232 > slaveServer.webcache: Flags [P.], seq 2909077325:2909077700, ack 2040056900, win 229, options [nop,nop,TS val 3094009310 ecr 3091944374], length 375: HTTP: POST /path/process3 HTTP/1.1 07:37:27.209286 IP slaveServer.webcache > xx.xx.xx.xx.53232: Flags [.], seq 1:2577, ack 3557, win 300, options [nop,nop,TS val 3091975099 ecr 3094009310], length 2576: HTTP: HTTP/1.1 200 07:37:27.404865 IP xx.xx.xx.xx.53551 > slaveServer.webcache: Flags [P.], seq 1996723440:1996723817, ack 1343133109, win 229, options [nop,nop,TS val 3094040204 ecr 3091975267], length 377: HTTP: POST /path/process4 HTTP/1.1 07:37:28.932928 IP slaveServer.webcache > xx.xx.xx.xx.53551: Flags [.], seq 1:2577, ack 3548, win 300, options [nop,nop,TS val 3091976823 ecr 3094040204], length 2576: HTTP: HTTP/1.1 200 07:37:29.120056 IP xx.xx.xx.xx.53580 > slaveServer.webcache: Flags [P.], seq 1734970332:1734970711, ack 390079555, win 229, options [nop,nop,TS val *3094041920 ecr 3091976982], length 379: HTTP: POST /path/process5 HTTP/1.108:51:23.325430 IP slaveServer.webcache > xx.xx.xx.xx.53580: Flags [.], seq 1:2577, ack 5366, win 326, options [nop,nop,TS val 3096411215 ecr 3094041920], length 2576: HTTP: HTTP/1.1 20008:51:23.607888 IP slaveServer.webcache > xx.xx.xx.xx.53580: Flags [.], seq 1:1289, ack 5366, win 326, options [nop,nop,TS val 3096411498 ecr 3094041920], length 1288: HTTP: HTTP/1.1 20008:51:24.066861 IP slaveServer.webcache > xx.xx.xx.xx.53580: Flags [.], seq 1:1289, ack 5366, win 326, options [nop,nop,TS val 3096411957 ecr 3094041920], length 1288: HTTP: HTTP/1.1 20008:51:24.985860 IP slaveServer.webcache > xx.xx.xx.xx.53580: Flags [.], seq 1:1289, ack 5366, win 326, options [nop,nop,TS val 3096412876 ecr 3094041920], length 1288: HTTP: HTTP/1.1 20008:51:26.821888 IP sla
[OT] Re: Question about DirResourceSet?
From a long-time (occasional) list contributor : That's a nice post, in many ways, and a good way to get quick and useful answers. I only regret that my own knowledge is not sufficient to provide such an answer. (We regularly complain at people posting to this list, when their post is "not nice", so I thought we should also from time to time give kudos when it is). On 14.10.2019 16:37, Robert Olofsson wrote: Hi! Some background: We are currently running tomcat (9.0.26) and we serve data to both html/webapp and to our java application. The java application uses a lot of the same jar files that our servlets use. We have had tomcat setup with two directories: 1) webapps//WEB-INF/lib (as usual for servlet classes) 2) webapps//clientdir/ (jar files for the java application). This means that we have a lot of duplication of jar files in these two directories. We would like to have the duplicate files in only one place, sure disk space is cheap, but data transfer takes time. We thought that having the jars in the clientdir would be nice. We have read the documentation for tomcat and found the resource handling and it looks like we could possibly use something like: We tested this lightly and things seems to work. Questions: Is there any problem with this? If so, do you know of any better way to accomplish this? Thanks /robo - 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: Any tutorials or hints about JSP using javax.script engines instead of Java?
Hi. On 12.10.2019 02:17, George S. wrote: I'm a little confused. What would one hope to gain by doing this? I'm not that much of an expert on Tomcat or its "ecological niche", but in a general overall point of view, I would tend to say that anything that "opens up" tomcat to more programmers and more users cannot really be a bad thing. As an example, maybe off-track : there are a lot of web applications based on ruby, python, javascript, perl, php, etc.. Mostly, they are based on development frameworks similar to the ones for JSP pages, only written in something else than java. Porting these to tomcat using the CGI model is not really practical, and translating them to Java and JSP isn't either. (Apart from the fact that in order to really dominate java, you pretty much have to spend all your time on it.) So if this "javax.script" would provide a shortcut to run, with minimal adaptations, pages written using some of these other languages, if only temporarily and as a prototype, why not ? Of course there is a cost, and as Christopher previously pointed out, some previous attempt at this did not seem to have had many takers, and it pretty much seems to have died by lack of interest. But then again, in terms of market coverage as a webserver, the cost for tomcat to be "single language centric", is certainly not null either. On 10/8/2019 9:11 AM, Rony G. Flatscher (Apache) wrote: Does anyone know of any tutorials that would demonstrate how to use any javax.script language in JSPs instead of Java (e.g. using Jython or JavaScript instead)? If not, any advice/hint how to realize/create such a functionality (for then creating such a tutorial instead) would be highly appreciated! ---rony - 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: tomcat with SiteMinder
On 11.10.2019 05:11, Bauer, Margaret M (Peggy) wrote: Has anyone used tomcat with SiteMinder without having a webserver in front of it? If so, where can I find the how to? In the SiteMinder documentation ? (No kidding. As I recall, they do provide examples with multiple webservers.) thank you, *Peggy * - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Any tutorials or hints about JSP using javax.script engines instead of Java?
On 08.10.2019 17:11, Rony G. Flatscher (Apache) wrote: Does anyone know of any tutorials that would demonstrate how to use any javax.script language in JSPs instead of Java (e.g. using Jython or JavaScript instead)? If not, any advice/hint how to realize/create such a functionality (for then creating such a tutorial instead) would be highly appreciated! I know nothing about the subject matter, but was searching Google for "javax.script language jsp" and found this : http://wi.wu.ac.at:8002/rgf/diplomarbeiten/BakkStuff/2010/201007_Ryabenkiy/201007_Ryabenkiy_WebScripting_ApacheTomCat_TagLib.pdf (look around page 50). Does this help ? On the side, even though (or maybe because) I did not previously know anything about this, I found this document really impressive in terms of providing a terse but extremely readable background of the whole thing, all the way to some practical examples, all in less than 100 pages. And this was a bachelor's thesis. So I don't know if it helps you, but I enjoyed it. Looking up the author in Google, it doesn't seem that he really needs my modest plaudits though. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Acessing static content - Tomcat 7 vs. Tomcat9
On 08.10.2019 13:41, Martin Knoblauch wrote: Hi Andre, thanks for the extensive response. this is really appreciated. See below for comments On Mon, Oct 7, 2019 at 10:27 PM André Warnier (tomcat) wrote: Hi. see at end. Then the browser tells me that "The page isn’t redirecting properly". What one can see above is that the POST is now redirected, but the trailing "/" is not added as I would have expected using the two mapper directives ... Not only that, but also all the subsequent browser GET requests for "/cb2/docs", get a 302 response with a HTTP header : Location: /cb2/docs So the browser immediately re-issues a request for "/cb2/docs", which receives the same response, etc. Until the (smart) browser realises that it is always requesting and receiving the same thing and calls quits. What you are showing above as log, is only the httpd access log. Do you have an access log enabled in tomcat, and do you see these same accesses there ? (And if yes, then forget all the rest below). Yes, we have access logging enabled for Tomcat and for the TC9 setup I *DO NOT* see requests for "/cb2/docs" in there. Looking at the TC7 setup I can find the access and redirect in the Tomcat access log: 160.46.219.110 - - [08/Oct/2019:12:49:31 +0200] "POST /cb2/docs HTTP/1.1" 302 - Aha. So it looks like, with Tomcat 9 in the back-end, these requests are not even being proxied to Tomcat, and that it is httpd in that case which returns the 302's. Why that would be, with everything else being identical, is also a puzzle to me. But it's still better that looking uselessly in some Tomcat configuration issue. Maybe this will give someone else on the list an idea .. In the meantime, a question : considering your JkMount/JkUnmount directives below, you do have some files locally under Apache httpd's filesystem, which you want to serve directly from httpd. Would you have any other configuration sections with which cover these files, and /may/ be interfering/overriding the JkMount/unmount logic ? (Agreed, this is a long shot, and whatever they are, they should do the same whether it is t7 or t9 in the back-end, but again, one never knows..) Or else, can you modify the "LogLevel" directive in httpd, so that you see (in the httpd error log) how (or if) these accesses are really being proxied to tomcat ? (à la "Loglevel info proxy:debug proxy_ajp:debug" e.g.) Have added "JkLogLevel debug" to the mod_jk setup. Nothing interesting to see there. So I am still confused here. Based on this, from a previous post : quote # # CB2 - Portal # # Mount the "/cb2" application to worker "cb2" # JkMount /cb2/* cb2 # # Unmount "/cb2/docs" from worker "cb2" to allow static content # beeing served by apache. Same for "/cb2/cgi-bin" # JkUnMount /cb2/docs/* cb2 So we JkUnMount the "/cb2/docs" directory from the application base in order to server the content directly from Apache. "docs" itself is a symbolic link pointing outside the application base. unquote , I would indeed tend to say that a request with the URL "/cb2/docs" SHOULD be proxied to tomcat (and that the redirect should thus be coming from tomcat), but better make absolutely sure maybe ? (hence the additional logging above) The thing I'm unsure of myself, is this : Apache httpd gets the original request first. Initially, it doesn't know if this request should be proxied to tomcat or not. So, in its "map to storage" phase - which happens fairly early in the request processing -, it might try to map this URL to its local filesystem. Because you do indeed have files locally under /cb2/docs/, it would then find that "/cb2/docs" is indeed a directory (or a link to ditto). Now two things can happen, depending on the stage at which the mod_jk proxying directives intervene in httpd : - either httpd considers that the request, being for a directory, should have a trailing "/", and *httpd* issues the 302 redirect to the browser, without even getting to the proxying-to-tomcat stage - or the proxying directive has insinuated itself somewhere in-between, and httpd does in fact proxy the original request to tomcat (rather than trying to map it to its own filesystem first), and it is tomcat (which also would need to find a directory at ../webapps/cb2/docs) which issues that redirect. I do not know which of the above is true, because I am unsure of the httpd request cycle stage at which mod_jk inserts its URL mapping logic. But the logs which you have so far provided do not really *prove* that these requests make it to tomcat. So, if it was me, before spending time maybe looking in the wrong place, I would want to make sure of that first. Another way would be to enable some local debugging console in the browser, and have a look at what thes
Re: user and certificate info is not passed to tomcat
On 08.10.2019 00:50, Magosányi Árpád wrote: On 10/7/19 11:29 PM, André Warnier (tomcat) wrote: DirectoryIndex off RewriteEngine Off AuthType openid-connect AllowOverride None AuthzDBDQuery "a correct database query" Require dbd-group allrepo LogLevel debug Nice. It have solved the problem, thank you very much. By adding the ssl related directives here I could pass the ssl info as well. So basically we have put the JkMount in a Location, and the other directives in another similar directive, as a kind of workaround? Think of it as follows : When httpd gets a request, - step 1 : it first looks only at the request URL, and it applies any directives that it finds in or sections which match that URL. - step 2 : then it tries to match the URL, with the filesystem on disk, and IF it finds a file that corresponds to that URL - step 3 : then it applies any or that apply to that file - step 4 : httpd serves the file back to the browser If you have JkMount directives that match the URL, then step 2, 3 and 4 above never happen, because the request will be passed to tomcat anyway, so it will never map to a file on the httpd filesystem. And if you have JkUnmount directives, that also match the URL, then they partially negate the matching JkMount, and they /force/ step 2, 3 and 4. The combination of JkMount/JkUnmount directives, with the httpd and sections, is sometimes a bit unclear, specially when they overlap. There is another syntax applicable to the proxying via mod_jk, which I prefer because I find that it makes the httpd URL mapping clearer, in a httpd configuration logic sense. You can find it here : http://tomcat.apache.org/connectors-doc/reference/apache.html section : Using SetHandler and Environment Variables Using that form, you do NOT use any "JkMount/JkUnmount" directives, you use only blocks, like : SetHandler jakarta-servlet SetEnv JK_WORKER_NAME worker1 DirectoryIndex off RewriteEngine Off AuthType openid-connect AllowOverride None AuthzDBDQuery "a correct database query" Require dbd-group allrepo LogLevel debug The combination of the , SetHandler and SetEnv, does the same as a separate "JkMount /servlet* worker1" and (in my view) it makes it clearer in the Apache httpd configuration file, to know which URLs get proxied to tomcat and which do not get proxied. Look at the example "" to see how you can have some static documents served by the httpd front-end directly (= not proxied to tomcat), and the real calls to tomcat servlets being proxied to tomcat. - 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: user and certificate info is not passed to tomcat
Adding to my own previous post : A posteriori, I saw a question here : https://stackoverflow.com/questions/58240796/pass-username-and-client-certificate-from-apache-to-tomcat-using-mod-jk that may be related to your question on this list. Examining the above, you problem may be in the httpd configuration : As I interpret it, the section that you mention, will not be taken into account for the URLs that you are proxying to tomcat. That is because sections only apply if the URL ultimately maps to a local file for httpd. In this case, it does not, because you are proxying this request to tomcat. For such URLs, you should use a or in httpd, not a . For example, *add* this to your httpd configuration : DirectoryIndex off RewriteEngine Off AuthType openid-connect AllowOverride None AuthzDBDQuery "a correct database query" Require dbd-group allrepo LogLevel debug Note: the above is very rough, and you may need to tune the regex a bit better. On 08.10.2019 00:11, André Warnier (tomcat) wrote: On 07.10.2019 23:24, Magosányi Árpád wrote: On 10/7/19 8:20 PM, André Warnier (tomcat) wrote: Forgot the atribute 'tomcatAuthentication="false"' in the Connector ? Yes, I did, however adding it back did not improve the situation. Ok. I just mentioned that, because it is one piece of the puzzle, and you might have forgotten it. What this piece really does is : - IF the front-end Apache httpd authenticates the HTTP request which it later passes on to tomcat - IF the protocol used between Apache httpd and tomcat is AJP - IF the AJP Connector in tomcat has the attribute set as above - THEN tomcat will retrieve the user-id of the httpd-authenticated user, and save it internally as the tomcat-authenticated user-id for this request So now you have the two last IF's answered positively. What about the first IF ? Info : in the default format of the Apache httpd access log, it will show the authenticated user (if any) for each request, for example like this : 127.0.0.1 - THEUSER [07/Oct/2019:21:18:20 +0200] "GET /starwebtt-internal/esearch... (where "THEUSER" is the httpd-authenticated user) while if the request is not authenticated by httpd, it will show a "-" instead of the user-id, like this : 127.0.0.1 - - [07/Oct/2019:21:18:20 +0200] "GET /starwebtt-internal/esearch... (and, of course, if httpd has not authenticated the request which it later passes on to tomcat via AJP, then it cannot pass a user-id to tomcat, and thus tomcat cannot retrieve this user-id, and thus the request, at the tomcat level, is not authenticated). Next comes the question of how the tomcat application retrieves this user-id, from tomcat itself. I suppose that this would be a question for the developers of the "com.kodekonveyor.realm.KKAuthorizationFilter" filter mentioned in your configuration below. (if the KKAuthorizationFilter does not use request.getRemoteuser(), but uses some other method, then you are out of luck for this front-end/back-end combination)(or you may need to do something additional at the front-end httpd level). My server.xml now: and my web.xml until mime mappings: http://xmlns.jcp.org/xml/ns/javaee; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd; version="4.0"> default org.apache.catalina.servlets.DefaultServlet debug 0 listings false 1 jsp org.apache.jasper.servlet.JspServlet fork false xpoweredBy false 3 default / jsp *.jsp *.jspx KKAuthorizationFilter com.kodekonveyor.realm.KKAuthorizationFilter KKAuthorizationFilter /* REQUEST 30 - 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: user and certificate info is not passed to tomcat
On 07.10.2019 23:24, Magosányi Árpád wrote: On 10/7/19 8:20 PM, André Warnier (tomcat) wrote: Forgot the atribute 'tomcatAuthentication="false"' in the Connector ? Yes, I did, however adding it back did not improve the situation. Ok. I just mentioned that, because it is one piece of the puzzle, and you might have forgotten it. What this piece really does is : - IF the front-end Apache httpd authenticates the HTTP request which it later passes on to tomcat - IF the protocol used between Apache httpd and tomcat is AJP - IF the AJP Connector in tomcat has the attribute set as above - THEN tomcat will retrieve the user-id of the httpd-authenticated user, and save it internally as the tomcat-authenticated user-id for this request So now you have the two last IF's answered positively. What about the first IF ? Info : in the default format of the Apache httpd access log, it will show the authenticated user (if any) for each request, for example like this : 127.0.0.1 - THEUSER [07/Oct/2019:21:18:20 +0200] "GET /starwebtt-internal/esearch... (where "THEUSER" is the httpd-authenticated user) while if the request is not authenticated by httpd, it will show a "-" instead of the user-id, like this : 127.0.0.1 - - [07/Oct/2019:21:18:20 +0200] "GET /starwebtt-internal/esearch... (and, of course, if httpd has not authenticated the request which it later passes on to tomcat via AJP, then it cannot pass a user-id to tomcat, and thus tomcat cannot retrieve this user-id, and thus the request, at the tomcat level, is not authenticated). Next comes the question of how the tomcat application retrieves this user-id, from tomcat itself. I suppose that this would be a question for the developers of the "com.kodekonveyor.realm.KKAuthorizationFilter" filter mentioned in your configuration below. (if the KKAuthorizationFilter does not use request.getRemoteuser(), but uses some other method, then you are out of luck for this front-end/back-end combination)(or you may need to do something additional at the front-end httpd level). My server.xml now: and my web.xml until mime mappings: http://xmlns.jcp.org/xml/ns/javaee; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd; version="4.0"> default org.apache.catalina.servlets.DefaultServlet debug 0 listings false 1 jsp org.apache.jasper.servlet.JspServlet fork false xpoweredBy false 3 default / jsp *.jsp *.jspx KKAuthorizationFilter com.kodekonveyor.realm.KKAuthorizationFilter KKAuthorizationFilter /* REQUEST 30 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Acessing static content - Tomcat 7 vs. Tomcat9
Hi. see at end. On 07.10.2019 16:26, Martin Knoblauch wrote: On Mon, Oct 7, 2019 at 3:31 PM Konstantin Kolinko wrote: пн, 7 окт. 2019 г. в 15:44, Martin Knoblauch : Hi Konstantin, On Mon, Oct 7, 2019 at 2:36 PM Konstantin Kolinko < knst.koli...@gmail.com> wrote: 2. For Tomcat to issue a redirect, the "docs" directory must be present in your web application. It can be empty, but it must be present. (If there is none, Tomcat does not know that the requested resource is a directory). OK. The "docs" directory is actually a symbolic link to a directory elsewhere. Symbolic links by default are not allowed inside a web application. The option to allow them differs between Tomcat 7 and 8.0, due to a different underlying implementation of Web Application resources. http://tomcat.apache.org/migration-8.html#Web_application_resources (As a reminders: symbolic links must never be enabled on a case-insensitive filesystem such as used by Windows, as it disables the necessary security checks.) http://tomcat.apache.org/tomcat-9.0-doc/security-howto.html Best regards, Konstantin Kolinko OK, this is interesting. We still had the TC7 style "allowLiniking" in the Context tag. Now moved to Resources. I also added the two mapper directives to Context: .. .. .. What I now get is weird in another way. But maybe it gives a hint: [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "POST /cb2/docs HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0" [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0" [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0" [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0" [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0" [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0" [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0" [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0" [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0" [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0" [07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0" [07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0" [07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0" [07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0" [07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0" [07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
Re: user and certificate info is not passed to tomcat
On 07.10.2019 17:36, Magosányi Árpád wrote:
Magosányi,
How are you getting the attributes from the request?
This is the filter code:
String user = httpRequest.getRemoteUser(); Object cert =
httpRequest.getAttribute("javax.servlet.request.X509Certificate");
this.context.log("user:"+user);
This won't show any username unless the user has logged-in using HTTP
Basic/Digest authentication. Are you using those?
I am using openid right now in the apache side, but also tested with
basic auth to make sure that it is not an interaction with mod_openidc.
The user information does not get passed along either in the remoteUser
attribute or anywhere, in either of those cases, in spite that the
documentation states that the authenticated user name should be
retrievable using httpRequest.getRemoteUser(), and the CGI clearly shows
that we indeed have a REMOTE_USER in the apache side.
To get the certificate chain, I think you also need this in your httpd
configuration:
JkOptions +ForwardSSLCertChain
I have added this now, though as I understand this is only needed if I
want to get the full chain.
Unfortunately this did not improve the situation in any way.
Forgot the atribute 'tomcatAuthentication="false"' in the Connector ?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Acessing static content - Tomcat 7 vs. Tomcat9
On 07.10.2019 13:45, Mark Thomas wrote: On 07/10/2019 12:22, Martin Knoblauch wrote: Dear fellow Tomcat users, recently we migrated our application from Tomcat7 to Tomcat9. Most things work great so far, but we observed on issue. Basically serving static pages has stopped for us. Our setup is Tomcat (7.0.62 or 9.0.12) behind Apache HTTPD (2.4.41 using mod_jk 1.2.46). Yes, 9.0.12 is not recent, but we are forced to that version. The mod_jk configuration basically looks like: LoadModule jk_module modules/mod_jk.so JkWorkersFile "conf/cb2/workers.properties" JkShmFile "logs/jk-runtime-status" JkLogFile "logs/mod_jk.log" JkLogLevel info JkWatchdogInterval 60 And then later inside a virtual host: # # CB2 - Portal # # Mount the "/cb2" application to worker "cb2" # JkMount /cb2/* cb2 # # Unmount "/cb2/docs" from worker "cb2" to allow static content # beeing served by apache. Same for "/cb2/cgi-bin" # JkUnMount /cb2/docs/* cb2 So we JkUnMount the "/cb2/docs" directory from the application base in order to server the content directly from Apache. "docs" itself is a symbolic link pointing outside the application base. With TC7, we observe the following in the apache access_log: [07/Oct/2019:12:30:47 +0200] [2 ms] 160.46.219.110 - "POST /cb2/docs HTTP/1.1" s:302 l:- S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 [07/Oct/2019:12:30:47 +0200] [20 ms] 160.46.219.110 - "GET /cb2/docs/ HTTP/1.1" s:200 l:6367 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 So the POST from the application is redirected to the static content, which is served OK. With TC9 we see: [05/Oct/2019:02:58:13 +0200] [0 ms] #160.46.219.110# - "GET /docs HTTP/1.1" s:404 l:196 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 Where and how is the redirect generated? As said, the major difference between the setups is TC7 vs. TC9. Any ideas for me to follow? I did not find anything in the migration 7->8 or 8->9 guides. I can't think of anything and a review of the migration guides doesn't bring anything to mind. I'd be looking more at configuration differences between the old and new systems at this point. Mark The URLs appear different : - the first case shows a URL of "/cb2/docs" (with some kind of redirect from POST to a GET). According to the mod_jk configuration, this is NOT being proxied to Tomcat. Assuming thus that the httpd DOCUMENT_ROOT is set to (e.g.) /var/www/docs, it would mean that the file being served is some directory list (or index document) located below /var/www/docs/cb2/docs/ (on the httpd host). - the second example shows a URL of "/docs", which according to the mod_jk configuration above is also NOT being proxied to Tomcat; thus Apache httpd attempts to serve it locally. But that URL does not match any Apache-httpd-local file (because /var/www/docs/docs does not exist), and thus results in a 404 status "not found". To verify this is quite simple : In the URL bar of a browser, enter the URL "http://yourservername/cb2/docs; directly, replacing "yourservername" alernatively with the one for tomcat 7 and the one for tomcat9. The result should be the same, because this URL is not being proxied to Tomcat, and is served locally by httpd. (On the other hand, the URL "/docs" should give "404 not found" in both cases too) What I suspect is : The above URL "/cb2/docs" is not being entered in the browser URL bar. Instead, the link to that URL occurs in a html page previously returned by Tomcat, and the user just clicks on the link. Then maybe it is that previous page returned by Tomcat, that is different between Tomcat 7 and Tomcat 9. (That could be consistent with "the major difference between the setups is TC7 vs. TC9."). Further speculation under incomplete information (I love this) : could it be that under Tomcat 7, your application is deployed under ../webapps/cb2, while under tomcat 9, you have relocated it to ../webapps/ROOT ? - 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: POST request fails if content is ignored?
On 09.09.2019 15:21, Leon Atherton wrote: Thank you for the suggestion. I have just tried playing with this value. Setting it to -1, and setting it to 100x larger than the default. In both cases, the behaviour seems unchanged. Without touching this value, Tomcat will accept multipart POST requests much larger than 2MB (which is the default) as long as you call request.getPart() or request.getParameter(). I haven't tried that, but as per the documentation that at least looks wrong. The problem I am seeing is that if a response is sent without calling one of those methods, the browsers see it as a failed request. To help me (or us) better understand the issue, could you provide a bit of context ? Such as : why would the client send content in a POST, if the service at the end of the target URL is not going to read that content ? What would be a use case ? (Mainly because my interpretation is that, if the browser does that, then at least in some way it /is/ a bad request, which /should/ fail). And maybe another question : have you tried monitoring such a request/response using a browser-based tracing tool, to show exactly what the server is sending back ? (is it e.g. some kind of 4xx response ?) Thanks On 09/09/2019 12:59, André Warnier (tomcat) wrote: Hi. Did you check : https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#Common_Attributes --> maxPostSize Note : normally, the browser will encode (Base64 or similar) the content of a file and send the encoded content, which tends to be significantly larger (in bytes) than the original file (say + 30%). I do not know (and the doc does not say) if the maxPostSize attribute refers to the POST content still encoded or already decoded. On 09.09.2019 12:53, Leon Atherton wrote: Hello, I've discovered an interesting issue where POST requests fail when uploading a file over about ~6MB if the server ignores the request content. I've put together a simple project to reproduce it: https://github.com/leonatherton/tomcat-request-issue Serverside code: https://github.com/leonatherton/tomcat-request-issue/blob/master/src/main/java/DemoServlet.java Clientside code: https://github.com/leonatherton/tomcat-request-issue/blob/master/src/main/webapp/index.html If you'd like to try it yourself there are a couple of pre-built war files on the releases page, and there are steps to reproduce in the README.md file. The problem does not occur when uploading a small file, and the problem can be "fixed" by simply getting a parameter from the request object. It reproduces in Tomcat 8 & 9. The problem does not reproduce on Payara, but I am seeing similar on Jetty. My guess is that the server responds before the client has finished uploading the file. The browsers see the incomplete upload and report this as an error, despite content being sent in response. And my guess is that inspecting a request parameter causes the server to wait for the full upload before sending the response. It's a slightly odd workflow, but it's not too unreasonable to sometimes respond early and ignore the request content. Is this expected behavior, or a bug in Tomcat? Thanks! Leon - 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 - 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?
Hi. Did you check : https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#Common_Attributes --> maxPostSize Note : normally, the browser will encode (Base64 or similar) the content of a file and send the encoded content, which tends to be significantly larger (in bytes) than the original file (say + 30%). I do not know (and the doc does not say) if the maxPostSize attribute refers to the POST content still encoded or already decoded. On 09.09.2019 12:53, Leon Atherton wrote: Hello, I've discovered an interesting issue where POST requests fail when uploading a file over about ~6MB if the server ignores the request content. I've put together a simple project to reproduce it: https://github.com/leonatherton/tomcat-request-issue Serverside code: https://github.com/leonatherton/tomcat-request-issue/blob/master/src/main/java/DemoServlet.java Clientside code: https://github.com/leonatherton/tomcat-request-issue/blob/master/src/main/webapp/index.html If you'd like to try it yourself there are a couple of pre-built war files on the releases page, and there are steps to reproduce in the README.md file. The problem does not occur when uploading a small file, and the problem can be "fixed" by simply getting a parameter from the request object. It reproduces in Tomcat 8 & 9. The problem does not reproduce on Payara, but I am seeing similar on Jetty. My guess is that the server responds before the client has finished uploading the file. The browsers see the incomplete upload and report this as an error, despite content being sent in response. And my guess is that inspecting a request parameter causes the server to wait for the full upload before sending the response. It's a slightly odd workflow, but it's not too unreasonable to sometimes respond early and ignore the request content. Is this expected behavior, or a bug in Tomcat? Thanks! Leon - 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: Tomcat 8.5.45 service error 1067
Hello Jason. Have a look at the archives of this mailing list, for the last 30 days or so. I think that there have been some issues with the tomcat(x).exe wrapper recently. And I believe (but don't trust me entirely on this) that one quick workaround was to copy the previous tomcat8.exe program on top of the one recently installed, and try again. On 08.09.2019 21:45, Jason Wong wrote: Hi. I have an application running on tomcat 8.0.53 (32-bit) running on windows 2008R2 server (64-bit), it runs fine. I'm looking to upgrade to tomcat 8.5.45 (32-bit). I downloaded the apache-tomcat-8.5.45.exe installer, verified the signature, and ran it (no errors). But when try to start the 8.5.45 service, it crashes immediately with: Windows could not start the Apache Tomcat 8.5 Tomcat85 service on Local Computer. Error 1067: The process terminated unexpectedly. Not much in the log files: commons-daemon log [2019-09-08 14:50:06] [debug] ( prunsrv.c:1754) [ 1952] Apache Commons Daemon procrun log initialized. [2019-09-08 14:50:06] [info] ( prunsrv.c:1758) [ 1952] Apache Commons Daemon procrun (1.2.0.0 32-bit) started. [2019-09-08 14:50:06] [info] ( prunsrv.c:1668) [ 1952] Running Service 'Tomcat85'... [2019-09-08 14:50:06] [debug] ( prunsrv.c:1441) [ 2460] Inside ServiceMain... [2019-09-08 14:50:06] [debug] ( prunsrv.c:904 ) [ 2460] reportServiceStatusE: dwCurrentState = 2, dwWin32ExitCode = 0, dwWaitHint = 3000, dwServiceSpecificExitCode = 0. [2019-09-08 14:50:06] [info] ( prunsrv.c:1196) [ 2460] Starting service... tomcat stderr log 2019-09-08 14:50:06 Apache Commons Daemon procrun stderr initialized. tomcat stdout log 2019-09-08 14:50:06 Apache Commons Daemon procrun stdout initialized. I uninstalled, downloaded again, reinstalled, but the same thing happens. One thing I find strange is that if I run my application using startup.bat in the tomcat 8.5.45 bin folder, it runs just fine. I'm using the same jvm.dll that my tomcat 8.0.53 service uses. I've tried a couple other jre versions but have the same problem. The windows event viewer has some additional error messages (below). I've searched with google but I can't find anything that could help. Any ideas? Thanks. Faulting application name: Tomcat85.exe, version: 1.2.0.0, time stamp: 0x5d15f1ac Faulting module name: ntdll.dll, version: 6.1.7601.24511, time stamp: 0x5d3fa86b Exception code: 0xc005 Fault offset: 0x00038120 Faulting process id: 0x17c Faulting application start time: 0x01d56673e1d91ab6 Faulting application path: C:\Apache Software Foundation\Tomcat 8.5_Tomcat85\bin\Tomcat85.exe Faulting module path: C:\Windows\SysWOW64\ntdll.dll Report Id: 200ff770-d267-11e9-ad87-00505681 Fault bucket , type 0 Event Name: APPCRASH Response: Not available Cab Id: 0 Problem signature: P1: Tomcat85.exe P2: 1.2.0.0 P3: 5d15f1ac P4: ntdll.dll P5: 6.1.7601.24511 P6: 5d3fa86b P7: c005 P8: 00038120 P9: P10: Attached files: These files may be available here: C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_Tomcat85.exe_1689eaa6183aaaf7cf6e93c94c2e1f6eadf2bfd_04e7a9d6 Analysis symbol: Rechecking for solution: 0 Report Id: 200ff770-d267-11e9-ad87-00505681 Report Status: 4 Fault bucket , type 0 Event Name: APPCRASH Response: Not available Cab Id: 0 Problem signature: P1: Tomcat85.exe P2: 1.2.0.0 P3: 5d15f1ac P4: ntdll.dll P5: 6.1.7601.24511 P6: 5d3fa86b P7: c005 P8: 00038120 P9: P10: Attached files: These files may be available here: C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_Tomcat85.exe_1689eaa6183aaaf7cf6e93c94c2e1f6eadf2bfd_04e7a9d6 Analysis symbol: Rechecking for solution: 0 Report Id: 200ff770-d267-11e9-ad87-00505681 Report Status: 0 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reg : Parameter Filters
On 05.09.2019 20:58, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Praveen, On 9/5/19 05:07, praveen kumar wrote: Hello, I am working with an application called geoserver which works on Apache Tomcat server. Just for an idea for those who donot know, geoserver is an application that serves web map services. When I am calling this service I will be providing a few parameters about the map like layer name, height, width and so on.., Now my requirement is to restrict the values passed to these parameters Like for example for WIDTH it should only consider an integer, if a request having a string for WIDTH should not reach my application. I am looking for some redirect rules but I could not succeed. It would be great if some one can help or guide me on this. LOL this service doesn't actually sanitize its input? Yikes. The good news is that you can do this in a few ways. You have 3 options that I can see: 1. Use a redirect filter 2. Use a reverse-proxy like Apache with some filtering configured 3. Write it yourself In order to use a redirect filter, you will have to: a. Choose a redirect filter (e.g. Tomcat's rewrite[1] or Tuckey's urlrewrite[2]) b. Configure it with a file. The configuration depends upon which filter you choose c. Bundle that filter+config with the application In order to use a reverse proxy, you'll need to: a. Choose a reverse proxy (e.g. Apache httpd, nginx, Squid, etc.) b. Configure it properly (which depends upon your choice in (a) above) In order to write it yourself, you will have to: a. Write a servlet filter in Java b. Package that filter into the application c. Install that filter into the filter-chain by modifying the application's WEB-INF/web.xml file Do you have a preference? - -chris +1, but I would have to add that first of all, Praveen should have a clear idea of /what he thinks should happen/, if one of the request parameters does not meet expectations. Saying that "the request should not make it to the application" is one thing, but what do you want to happen instead ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
