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: 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: 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
