Re: 500 instances of tomcat on the same server

2021-06-28 Thread John Larsen
No need to be discouraged. Docker is just a set of tools. You can still use
docker to create images, but you dont need docker to use those images in a
container. K8s is using industry standard containerd.
https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/


John Larsen



On Mon, Jun 28, 2021 at 2:22 PM Eric Robinson 
wrote:

> Guido,
>
> I think you intended that message for me, not Brian. Thanks much for the
> feedback. I have been reading about Kubernetes, but I got discouraged when
> I saw that they dropped Docker support, since Docker seems to be the most
> popular containeriziation technology. Also, most of the Kubernetes
> tutorials I saw on YouTube seem to approach it as a dev platform, and we're
> not developers.
>
> -Eric
>
>
> > -Original Message-
> > From: Guido Jäkel 
> > Sent: Monday, June 28, 2021 2:43 PM
> > To: Brian Wolfe 
> > Cc: Tomcat Users List 
> > Subject: Re: 500 instances of tomcat on the same server
> >
> > Dear Brian,
> >
> > please take the time to read about Linux Kernel namespaces as the
> technical
> > base of containers. It's like two viewpoints to one thing. Take the
> network
> > namespace as an example: From the conceptual point of view it looks like
> > you have N indipended, functional identical "IP Stacks". But from the
> > technical point of view, it's just the "well known" single instance just
> with an
> > additional field at all items that need this (packets, routing tables,
> ...) to take
> > a tag value that identify the namespace instance.
> >
> > You may use namespaces with the raw tools like enterns or with LXC or
> > Dockers. During runtime of a started container, there's nothing more you
> > have to trust but the kernel because for the basics, there's no need of
> > additional userland processes to keep a container running.
> >
> > To run an application in a "container", you start it with a bunch of
> instances of
> > this namespaces, at least the process namespace. You'll probably take the
> > same name for the technical namespace instances - from the conceptual
> > point of view this is the name of the container.
> >
> > Most will start something like the init binary located in a directory
> tree of a
> > small Linux distribution userland. This may "boot" common services and
> the
> > result may act like an "indipended platfrom". But you may also launch
> just
> > single high-level applications like a JVM running a Tomcat.
> >
> > That's very close to your architecture, but much more easy to handle.
> For the
> > network stack e.g. you may use the same ports for listeners and have the
> full
> > range of ports available for connections in each namespace. There are
> > different ways available to route the traffic, but in any case you may
> use
> > individual IPs in each namespace.
> >
> > greetings
> >
> > Guido
> >
> > On 2021-06-28 19:22, Brian Wolfe wrote:
> > > Generally, I'd agree too. We are considering using containers, but I'm
> > > not yet sure what that buys us in terms of stability.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
>
> Disclaimer : This email and any files transmitted with it are confidential
> and intended solely for intended recipients. If you are not the named
> addressee you should not disseminate, distribute, copy or alter this email.
> Any views or opinions presented in this email are solely those of the
> author and might not represent those of Physician Select Management.
> Warning: Although Physician Select Management has taken reasonable
> precautions to ensure no viruses are present in this email, the company
> cannot accept responsibility for any loss or damage arising from the use of
> this email or attachments.
>


Re: Question about TLS/SSL setup and SSLHostConfig or not

2021-03-02 Thread John Larsen
I usually let the apache webserver or nginx handle the SSL while proxying
to the tomcat.  To use tomcat's built in server you'll need to import the
SSL certificate into the keystore via your jdk.


John Larsen



On Tue, Mar 2, 2021 at 3:06 PM Alex  wrote:

> Hi.
>
> I try to make a "good" tomcat config and read the docs.
>
> Now in the Connector doc is the following statement.
>
> http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support
> http://tomcat.apache.org/tomcat-10.0-doc/config/http.html#SSL_Support
>
> Each secure connector must define at least one SSLHostConfig.
>
> But when I look into the SSL/TLS Configuration How-To is the snipplet
> without SSLHostConfig. What's now the "best" way to setup TLS/SSL
> with tomcat. I would prefer to put SSLHostConfig but I'm not sure if
> it's the way how the developer think to setup the TLS in tomcat?
>
> I use JSSE as implementation.
>
> http://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html
> http://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html
>
> ```
> 
>  protocol="org.apache.coyote.http11.Http11NioProtocol"
> port="8443" maxThreads="200"
> scheme="https" secure="true" SSLEnabled="true"
> keystoreFile="${user.home}/.keystore" keystorePass="changeit"
> clientAuth="false" sslProtocol="TLS"/>
> ```
>
> What's your suggestion and opinion to configure the tomcat in a
> proper way to use TLS also for the future versions.
>
> Regards
> Alex
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: Recognizing Certificate Updates

2020-12-26 Thread John Larsen
This is why we set up SSL through the web server instead of tomcat.
Apache webserver -> SSL -> Mod_jk <-> Tomcat

John Larsen



On Sat, Dec 26, 2020 at 10:43 AM Jerry Malcolm 
wrote:

> We have a production environment where we rarely reboot Tomcat.
> LetsEncrypt auto-updates the certificates every couple of months. But
> the new certificates are not loaded into Tomcat.  So when the original
> expiration date of the certs arrives, users get "certificate expired"
> even though new certs exist.  A simple reboot to load the new certs
> fixes it.  But we want to avoid reboots.  Are there any config
> parameters that tell TC to check for cert updates and reload the new
> certs?  Thx
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: CentOS Tomcat install seems to ignore setenv.sh

2020-05-12 Thread John Larsen
Should be chmod 644 and also I wouldnt recommend running tomcat as root.

John Larsen



On Tue, May 12, 2020 at 9:28 AM Patrick Baldwin 
wrote:

> I've gotten passed an odd (to me, anyway) issue with one of our clients
> CentOS systems.
>
> When our webapp starts running, tomcat dies shortly thereafter with an
> OutOfMemoryError. This apparently just started a few days ago.
>
> System info:
>
> Tomcat Version: Apache Tomcat/7.0.76
>
> JVM version: 1.8.0_191-b12
>
> OS: CentOS Linux release 7.6.1810 (Core)
>
>
> This seemed to indicate that catalina.sh isn’t the place for environment
> variables on Tomcat 7 for Linux:
>
> https://forums.centos.org/viewtopic.php?t=54207
>
>
> Since there isn’t a setenv.sh in /usr/local/tomcat/bin, we create one:
>
> https://stackoverflow.com/questions/9480210/tomcat-7-setenv-sh-is-not-found
>
> 195$ ls -l /usr/local/tomcat/bin/setenv.sh
>
> -rwxrwxrwx. 1 root tomcat 110 May 11 12:56 /usr/local/tomcat/bin/setenv.sh
>
> 45$ cat /usr/local/tomcat/bin/setenv.sh
>
> export CATALINA_OPTS="-server -Xms2048m -Xmx2048m"
>
> export JAVA_OPTS="-XX:PermSize=256m -XX:MaxPermSize=2048m"
>
> 46$
>
>
> System memory before starting tomcat:
>
> 188$ free -h
>
>   totalusedfree  shared  buff/cache
> available
>
> Mem:11G2.3G2.2G2.0G7.1G
> 6.7G
>
> Swap:  8.0G1.0G7.0G
>
>
> Started tomcat,  with sudo service tomcat start
>
> Tomcat journal error:
>
>
> May 11 17:48:59 protrack server[7298]: SEVERE: Unexpected death of
> background thread ContainerBackgroundProcessor[StandardEngine[Catalina]]
>
> May 11 17:48:59 protrack server[7298]: java.lang.OutOfMemoryError: GC
> overhead limit exceeded
>
> May 11 17:48:59 protrack server[7298]: Exception in thread
> "ContainerBackgroundProcessor[StandardEngine[Catalina]]"
> java.lang.OutOfMemoryError: GC overhead limit exceeded
>
> May 11 17:49:38 protrack server[7298]: Exception:
> java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in
> thread "http-bio-8080-AsyncTimeout"
>
> May 11 17:49:39 protrack server[7298]: Exception:
> java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in
> thread "ajp-bio-8009-AsyncTimeout"
>
> May 11 17:49:42 protrack server[7298]: Exception in thread
>
> "org.springframework.scheduling.quartz.SchedulerFactoryBean#0_QuartzSchedulerThread"
>
>
> Application log error:
>
> Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
>
> 2020-05-11 17:49:50
> [org.springframework.scheduling.quartz.SchedulerFactoryBean#0_Worker-2]
> ERROR o.s.t.i.TransactionInterceptor - Application exception overridden by
> rollback exception
>
> java.lang.OutOfMemoryError: GC overhead limit exceeded
>
>
> System memory while tomcat is up, after the OutOfMemoryError pops:
>
> ksmq_tv 191$ free -h
>
>   totalusedfree  shared  buff/cache
> available
>
> Mem:11G3.5G1.0G2.0G7.1G
> 5.5G
>
> Swap:  8.0G1.0G7.0G
>
>
> Stopped with  sudo service tomcat stop
>
>
>
> System memory after tomcat stopped:
>
> ksmq_tv 194$ free -h
>
>   totalusedfree  shared  buff/cache
> available
>
> Mem:11G795M3.7G2.0G7.1G
> 8.2G
>
> Swap:  8.0G1.0G7.0G
>
>
>
> It sure doesn't look like something is actually running the system out of
> memory at a system level; usage is definitely impacted by starting our app,
> but that's expected.
>
> Assuming no one finds any obvious errors with how we implemented setenv.sh,
> is there some way to verify what memory limitations tomcat is actually
> running under?
>
> I was also wondering if anyone knew an open source webapp that would be
> good to deploy to see if this problem is tomcat specific or an issue with
> our webapp?  I figure if I deploy something else that doesn't promptly
> throw an  OutOfMemoryError, then it might be more of a dev issue and less
> of a tomcat config issue.  Trying to at least figure out what direction I
> need to be looking in, any help much appreciated.
>


Re: Strange behavior when deploying new war

2020-04-23 Thread John Larsen
Turns out the developer was deleting the app dir along with war and
restarting.

John

On Thu, Apr 23, 2020 at 1:19 PM John Larsen 
wrote:

> Ah doing ROOT.war is my pet peeve. I find this bad practice. Its nice to
> have ROOT especially when the developer insists theres something wrong with
> tomcat when really its their webapp. Having ROOT intact, can show that by
> removing their webapp and tomcat works.
>
> As for "/" vs "" - not sure that would solve the problem - i mean
> logically it doesnt make sense, but I will give it a try.
>
> John Larsen
>
>
> On Thu, Apr 23, 2020 at 1:15 PM Mark Thomas  wrote:
>
>> On 23/04/2020 20:10, John Larsen wrote:
>> > Ok so my next question is how to handle this better? The goal here is so
>> > that one does not have to enter /webappName/ on the end of the domain.
>> > We use the context to tell Tomcat which webapp to load instead of ROOT.
>>
>> Name the file "ROOT.war"
>>
>> And if you need some sort of identifier on the file:
>> "ROOT##alnomost-any-text-you-like.war"
>>
>> In the meantime, try specifying the path in server.xml as "" rather than
>> "/".
>>
>> Mark
>>
>>
>> >
>> > John Larsen
>> >
>> >
>> > On Thu, Apr 23, 2020 at 12:47 PM Christopher Schultz <
>> > ch...@christopherschultz.net> wrote:
>> >
>> > John,
>> >
>> > On 4/23/20 14:38, John Larsen wrote:
>> >>>> New tomcats 9.0.34 seems to fail when uploading new war when theres
>> >>>> a context in server.xml pointing to the particular exploded war.
>> >>>> Says 'The main resource set specified is not valid.' It's like hot
>> >>>> deploy is deleting the old webapp and restarting tomcat?
>> >>>>
>> >>>> > >>>>
>> >>>> docBase="/home/some/path/tomcat/webapps/webappName">
>> >>>>
>> >>>> 
>> >>>>
>> >>>> To work around this one has to comment out the above context, start
>> >>>> tomcat so the war will deploy, uncomment and then restart tomcat
>> >>>> again.
>> >
>> > Is there a compelling reason to have  in your conf/server.xml
>> > file at all? It sounds like it's not doing anything for you; indeed it
>> > it giving you a headache.
>> >
>> > -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
>>
>> --
​
John Larsen
__
<https://javapipe.com/>
<https://www.facebook.com/Javapipe/>   <https://twitter.com/JavaPipe>
<https://www.linkedin.com/company/javapipe-llc>


Re: Strange behavior when deploying new war

2020-04-23 Thread John Larsen
Ah doing ROOT.war is my pet peeve. I find this bad practice. Its nice to
have ROOT especially when the developer insists theres something wrong with
tomcat when really its their webapp. Having ROOT intact, can show that by
removing their webapp and tomcat works.

As for "/" vs "" - not sure that would solve the problem - i mean logically
it doesnt make sense, but I will give it a try.

John Larsen


On Thu, Apr 23, 2020 at 1:15 PM Mark Thomas  wrote:

> On 23/04/2020 20:10, John Larsen wrote:
> > Ok so my next question is how to handle this better? The goal here is so
> > that one does not have to enter /webappName/ on the end of the domain.
> > We use the context to tell Tomcat which webapp to load instead of ROOT.
>
> Name the file "ROOT.war"
>
> And if you need some sort of identifier on the file:
> "ROOT##alnomost-any-text-you-like.war"
>
> In the meantime, try specifying the path in server.xml as "" rather than
> "/".
>
> Mark
>
>
> >
> > John Larsen
> >
> >
> > On Thu, Apr 23, 2020 at 12:47 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > John,
> >
> > On 4/23/20 14:38, John Larsen wrote:
> >>>> New tomcats 9.0.34 seems to fail when uploading new war when theres
> >>>> a context in server.xml pointing to the particular exploded war.
> >>>> Says 'The main resource set specified is not valid.' It's like hot
> >>>> deploy is deleting the old webapp and restarting tomcat?
> >>>>
> >>>>  >>>>
> >>>> docBase="/home/some/path/tomcat/webapps/webappName">
> >>>>
> >>>> 
> >>>>
> >>>> To work around this one has to comment out the above context, start
> >>>> tomcat so the war will deploy, uncomment and then restart tomcat
> >>>> again.
> >
> > Is there a compelling reason to have  in your conf/server.xml
> > file at all? It sounds like it's not doing anything for you; indeed it
> > it giving you a headache.
> >
> > -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: Strange behavior when deploying new war

2020-04-23 Thread John Larsen
Ok so my next question is how to handle this better? The goal here is so
that one does not have to enter /webappName/ on the end of the domain.
We use the context to tell Tomcat which webapp to load instead of ROOT.

John Larsen


On Thu, Apr 23, 2020 at 12:47 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> John,
>
> On 4/23/20 14:38, John Larsen wrote:
> > New tomcats 9.0.34 seems to fail when uploading new war when theres
> > a context in server.xml pointing to the particular exploded war.
> > Says 'The main resource set specified is not valid.' It's like hot
> > deploy is deleting the old webapp and restarting tomcat?
> >
> >  >
> > docBase="/home/some/path/tomcat/webapps/webappName">
> >
> > 
> >
> > To work around this one has to comment out the above context, start
> > tomcat so the war will deploy, uncomment and then restart tomcat
> > again.
>
> Is there a compelling reason to have  in your conf/server.xml
> file at all? It sounds like it's not doing anything for you; indeed it
> it giving you a headache.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6h4pwACgkQHPApP6U8
> pFgkhw/7BGcgqAHCvwsp9n/ZaO1R9IvWNI2bYaznY/bkrhLjuDMFhcg7AFUUjBR3
> EITRLM5MyBHf1Uo0mdRwVQxkGbpgbgctJ4cdFY+B/cuPZoqNt26xmQO3CW3J8SFO
> 7ij5YDos5wIeXBhueQdT9blMFgLAQ/d6tkyRqQSazZlMs5rnXRUcKhU8QLgRXSF0
> 431I3/vQnzekM4eHA8jTe23zPkOVHOfF+LEtWSlVVif+7DaisrKw8DVR62mhrO/U
> 3IpPT8xO8Hwj3wglSEslbMV2dIVlUBzLrrMOlXxmkPdbXEZHJEatGoqC35vsJAq4
> Jxp7gbueSTZZKeFaq6nYbV2wwQo4uE5jU95hVe21EMqtFWm+Kx6fzRIqGkcph9IT
> A0HYxdi8J61NMMjHkwvaBhHBQscSq5N2P3uPi6WMMxDxKr2TrlggoP+9JfMaLmgP
> Z+HIdFB05QxXKJC28LuYbY2LGO87jWl0IHNsV+5/Y0TJDXzaZuLxLPRWTDfzCHkd
> d4xknKyfOd+GnZbThtmPSPPX9uZxBc6Yvb77vbjCKWhbtKPSknQrwWoIykQHLwgX
> Xghl3asjpDm5nD+ZPEKYZKeEsQVfvGGy1BFv+DncV1RVea0gEhMYlNqv7pUQCyS9
> 6DUNysW7ONkOkdit48W0tnF6xc5Wgzf6hUY8knAexH/LB810TbQ=
> =GVSH
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Strange behavior when deploying new war

2020-04-23 Thread John Larsen
New tomcats 9.0.34 seems to fail when uploading new war when theres a
context in server.xml pointing to the particular exploded war.  Says 'The
main resource set specified is not valid.' It's like hot deploy is deleting
the old webapp and restarting tomcat?





To work around this one has to comment out the above context, start tomcat
so the war will deploy, uncomment and then restart tomcat again.

John Larsen


Re: Tomcat 8.5.51 >> Use AJP Connector >> 403

2020-02-18 Thread John Larsen
It doesn't work otherwise. Before you guys changed the AJP we always used
locahost for host in workers.

John Larsen



On Tue, Feb 18, 2020 at 9:27 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> John,
>
> On 2/18/20 07:49, John Larsen wrote:
> > Worker host also needs to be 127.0.0.1 in your mod_jk
> > workers.properties file.  That is if you were using host=localhost
> > previously.
>
> Why?
>
> - -chris
>
> > On Tue, Feb 18, 2020 at 5:36 AM Friderike Hofmeister <
> > friderike.hofmeis...@mbsupport.de> wrote:
> >
> >> Hi,
> >>
> >> for our application we have to use the AJP protocol and so I
> >> understand with Tomcat 8.5.51 we have to configure the AJP
> >> connector as follows:
> >>
> >>  >> redirectPort="8443" secretRequired="false" secret="" />
> >>
> >> With this browser error message changed to "403 -- Der Server hat
> >> die Anfrage verstanden, verbietet aber eine Autoriesierung."
> >>
> >> So, probably we have to use the attribute
> >> allowedRequestAttributesPattern as well. But how? The
> >> documentation gives no example and the description there does not
> >> give me any idea how to use it.
> >>
> >> Regards and thanks in advance,
> >>
> >> Friderike Hofmeister DBA
> >>
> >> mb Support GmbH Friedenstr. 18 D-93053 Regensburg
> >>
> >> Tel.: +49 941 94 260-0 Hotline: +49 941 94 260-123 Fax: +49 941
> >> 94 260-111 E-Mail: friderike.hofmeister @mbsupport.de
> >>
> >> Web: www.mbsupport.de (http://www.mbsupport.de/) Sitz der
> >> Gesellschaft: Regensburg
> >>
> >> Geschäftsführer: Martin Böddecker Handelsregister: Amtsgericht
> >> Regensburg HRB 6469 Ust-IdNr. DE 8138 78197
> >>
> >> Hinweise zur Verarbeitung Ihrer personenbezogenen Daten:
> >> Verantwortlich für die Verarbeitung Ihrer personenbezogenen Daten
> >> im Rahmen des vorliegenden Kontakts ist die mb Support GmbH.
> >> Weitere Informationen zur Verarbeitung Ihrer Daten, insbesondere
> >> zu den Ihnen zustehenden Rechten, können Sie unserer Webseite
> >> unter https://mbsupport.de/index.php/datenschutz entnehmen oder
> >> auf jedem anderen Wege unter den o.g. Kontaktdaten bei uns
> >> erfragen.
> >>
> >> E-Mail Disclaimer Der Inhalt dieser E-Mail ist ausschließlich für
> >> den bezeichneten Adressaten bestimmt. Wenn Sie nicht der
> >> vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein
> >> sollten, so beachten Sie bitte, dass jede Form der Kenntnisnahme,
> >> Veröffentlichung, Vervielfältigung oder Weitergabe des Inhalts
> >> dieser E-Mail unzulässig ist. Wir bitten Sie, sich in diesem
> >> Fall mit dem Absender der E-Mail in Verbindung zu setzen. The
> >> information contained in this email is intended solely for the
> >> addressee. Access to this email by anyone else is unauthorized.
> >> If you are not the intended recipient, any form of disclosure,
> >> reproduction, distribution or any action taken or refrained from
> >> in reliance on it, is prohibited and may be unlawful. Please
> >> notify the sender immediately.
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5MC2MACgkQHPApP6U8
> pFgzqRAAkDvXVrBRgT8soWBKRNkYqaYdzdEWmX2IZWFj9R2+peYv95YDGRaxiPC7
> i295iVfg5U6JDChgWjm5epQc4wN3KJSYzg3ChskJ8S/mMEiqn9+Yeonmvhdb3rZb
> yiu8GB+bQgtfzp38fTzxugfM0B75vitvfZh7Tc5fkLLRg3EhC5J1gemc0hq+jXfs
> 0ezBUV/tghJdG3P/Xc0b7aMvkFJKlEXdyRaWNOUJ1x68LsTkc/2AofNB0WKTlYUb
> ysZdPMmCVBRCZaYfexVYU7xB3Dfmmnk+38Y18UJIupcjE9SBtqp7Z6hjdh9icY/H
> 2nc8YZxBI1V2Z+Y7+OxLjXc0BFK1rQDvUNi/FUraUjKnV+l6hPBFgVd8waX/FJoZ
> Iugy+ds55dYGgViM8NdWqzVf302fHhOpFHmlbEFmPjB55yfqU4c7qMfWS26wFzsV
> PQh3r0g2GJbXS1UitXBVrya50/eEQLI31CYcn5+tFGPtvZFfUMmHx/Gpc5aUr1io
> FiZuxbb+KX8EC64u+4lWDDIVvg1vyaBdASU+39OSmir4hmWNELZD6czXIUkLCGyu
> 7/bOUgFGiUIP44SehRwCT6aR0gq0buLvGijsyeSSFreozaCXbW0UnfwtP3y1i6Y7
> N9zu0Xm6QGVSrDWbpUSjmAoqUy1woSxKvuhqKwNMiILdGJn2Xhk=
> =rWyG
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: Tomcat 8.5.51 >> Use AJP Connector >> 403

2020-02-18 Thread John Larsen
I assumed. That was the case for us when the ajp connector changed.

John

On Tue, Feb 18, 2020 at 5:59 AM Friderike Hofmeister <
friderike.hofmeis...@mbsupport.de> wrote:

> Hi John,
>
> currently we do not make usage of mod_jk and workers.properties.
> Does your post mean we have to implement it?
>
> Regards,
> Friderike Hofmeister
>
> >
>
> > John Larsen  hat am 18. Februar 2020 13:49
> geschrieben:
> >
> >
> > Worker host also needs to be 127.0.0.1 in your mod_jk workers.properties
> > file.  That is if you were using host=localhost previously.
> >
> > John Larsen
> >
> >
> > On Tue, Feb 18, 2020 at 5:36 AM Friderike Hofmeister <
> > friderike.hofmeis...@mbsupport.de> wrote:
> >
> > > Hi,
> > >
> > > for our application we have to use the AJP protocol and so I understand
> > > with Tomcat 8.5.51 we have to configure the AJP connector as follows:
> > >
> > >  > > protocol="AJP/1.3"
> > > address="127.0.0.1"
> > > redirectPort="8443"
> > > secretRequired="false"
> > > secret=""
> > > />
> > >
> > > With this browser error message changed to "403 -- Der Server hat die
> > > Anfrage verstanden, verbietet aber eine Autoriesierung."
> > >
> > > So, probably we have to use the attribute
> allowedRequestAttributesPattern
> > > as well. But how?
> > > The documentation gives no example and the description there does not
> give
> > > me any idea how to use it.
> > >
> > > Regards and thanks in advance,
> > >
> > > Friderike Hofmeister
> > > DBA
> > >
> > > mb Support GmbH
> > > Friedenstr. 18
> > > D-93053 Regensburg
> > >
> > > Tel.: +49 941 94 260-0
> > > Hotline: +49 941 94 260-123
> > > Fax: +49 941 94 260-111
> > > E-Mail: friderike.hofmeister @mbsupport.de
> > >
> > > Web: www.mbsupport.de (http://www.mbsupport.de/)
> > > Sitz der Gesellschaft: Regensburg
> > >
> > > Geschäftsführer: Martin Böddecker
> > > Handelsregister: Amtsgericht Regensburg HRB 6469
> > > Ust-IdNr. DE 8138 78197
> > >
> > > Hinweise zur Verarbeitung Ihrer personenbezogenen Daten: Verantwortlich
> > > für die Verarbeitung Ihrer personenbezogenen Daten im Rahmen des
> > > vorliegenden Kontakts ist die mb Support GmbH. Weitere Informationen
> zur
> > > Verarbeitung Ihrer Daten, insbesondere zu den Ihnen zustehenden
> Rechten,
> > > können Sie unserer Webseite unter
> > > https://mbsupport.de/index.php/datenschutz entnehmen oder auf jedem
> > > anderen Wege unter den o.g. Kontaktdaten bei uns erfragen.
> > >
> > > E-Mail Disclaimer
> > > Der Inhalt dieser E-Mail ist ausschließlich für den bezeichneten
> > > Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser
> E-Mail
> > > oder dessen Vertreter sein sollten, so beachten Sie bitte, dass jede
> Form
> > > der Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe
> des
> > > Inhalts dieser E-Mail unzulässig ist. Wir bitten Sie, sich in diesem
> Fall
> > > mit dem Absender der E-Mail in Verbindung zu setzen.
> > > The information contained in this email is intended solely for the
> > > addressee. Access to this email by anyone else is unauthorized. If you
> are
> > > not the intended recipient, any form of disclosure,
> > > reproduction, distribution or any action taken or refrained from in
> > > reliance on it, is prohibited and may be unlawful. Please notify the
> sender
> > > immediately.
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > >
> > >
>
-- 
​
John Larsen
__
<https://javapipe.com/>
<https://www.facebook.com/Javapipe/>   <https://twitter.com/JavaPipe>
<https://www.linkedin.com/company/javapipe-llc>


Re: Tomcat 8.5.51 >> Use AJP Connector >> 403

2020-02-18 Thread John Larsen
Worker host also needs to be 127.0.0.1 in your mod_jk workers.properties
file.  That is if you were using host=localhost previously.

John Larsen


On Tue, Feb 18, 2020 at 5:36 AM Friderike Hofmeister <
friderike.hofmeis...@mbsupport.de> wrote:

> Hi,
>
> for our application we have to use the AJP protocol and so I understand
> with Tomcat 8.5.51 we have to configure the AJP connector as follows:
>
>  protocol="AJP/1.3"
> address="127.0.0.1"
> redirectPort="8443"
> secretRequired="false"
> secret=""
> />
>
> With this browser error message changed to "403 -- Der Server hat die
> Anfrage verstanden, verbietet aber eine Autoriesierung."
>
> So, probably we have to use the attribute allowedRequestAttributesPattern
> as well. But how?
> The documentation gives no example and the description there does not give
> me any idea how to use it.
>
> Regards and thanks in advance,
>
> Friderike Hofmeister
> DBA
>
> mb Support GmbH
> Friedenstr. 18
> D-93053 Regensburg
>
> Tel.: +49 941 94 260-0
> Hotline: +49 941 94 260-123
> Fax: +49 941 94 260-111
> E-Mail: friderike.hofmeister @mbsupport.de
>
> Web: www.mbsupport.de (http://www.mbsupport.de/)
> Sitz der Gesellschaft: Regensburg
>
> Geschäftsführer: Martin Böddecker
> Handelsregister: Amtsgericht Regensburg HRB 6469
> Ust-IdNr. DE 8138 78197
>
> Hinweise zur Verarbeitung Ihrer personenbezogenen Daten: Verantwortlich
> für die Verarbeitung Ihrer personenbezogenen Daten im Rahmen des
> vorliegenden Kontakts ist die mb Support GmbH. Weitere Informationen zur
> Verarbeitung Ihrer Daten, insbesondere zu den Ihnen zustehenden Rechten,
> können Sie unserer Webseite unter
> https://mbsupport.de/index.php/datenschutz entnehmen oder auf jedem
> anderen Wege unter den o.g. Kontaktdaten bei uns erfragen.
>
> E-Mail Disclaimer
> Der Inhalt dieser E-Mail ist ausschließlich für den bezeichneten
> Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser E-Mail
> oder dessen Vertreter sein sollten, so beachten Sie bitte, dass jede Form
> der Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe des
> Inhalts dieser E-Mail unzulässig ist. Wir bitten Sie, sich in diesem Fall
> mit dem Absender der E-Mail in Verbindung zu setzen.
> The information contained in this email is intended solely for the
> addressee. Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any form of disclosure,
> reproduction, distribution or any action taken or refrained from in
> reliance on it, is prohibited and may be unlawful. Please notify the sender
> immediately.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: what to do with address="::1"?

2020-02-14 Thread John Larsen
Thanks for the info. Will this change be backported to 8.5 and 7?

John Larsen



On Fri, Feb 14, 2020 at 9:03 AM Mark Thomas  wrote:

> On 14/02/2020 15:56, John Larsen wrote:
> > From my testing.
> >
> > secretRequired="false" is still needed though docs says its deprecated in
> > favor of just secret.
>
> Not correct.
>
> You are confusing requiredSecret (which has been deprecated in favour of
> secret) with secretRequired.
>
> > I also had to change the worker from host=localhost to host=127.0.0.1
>
> That suggests that localhost resolves to something other than 127.0.0.1
>
> > Also AJP13 connector protocol block is commented out where it never was
> > before.
> >
> > I'd prefer acceptance of localhost by default and then add secret for
> > remote ajp servers.
>
> While that might be secure enough by default for your use case it isn't
> secure enough by default for those users when not all users with the
> ability to log on to the host are considered trusted.
>
> Mark
>
>
> >
> > John Larsen
> >
> > On Fri, Feb 14, 2020 at 7:37 AM Mark Thomas  wrote:
> >
> >> On 14/02/2020 14:21, John Larsen wrote:
> >>> I apologize - coffee started to kick in.  The address="::1"  portion is
> >>> commented out.
> >>>
> >>> Will adding  secret="false"? in the server.xml bypass this issue?
> >>>
> >>>  >>> redirectPort="8443" />
> >>
> >> That will give you an AJP connector that is only listening on the
> >> loopback interface.
> >>
> >> Mark
> >>
> >>
> >>>
> >>> Thanks,
> >>>
> >>> John Larsen
> >>>
> >>> On Fri, Feb 14, 2020 at 6:52 AM Mark Thomas  wrote:
> >>>
> >>>> On 14/02/2020 13:45, John Larsen wrote:
> >>>>> Seems tomcat 9.0.31 has thrown me a curve and messed up my
> automation.
> >>>>>
> >>>>> Where can i understand this change better?
> >>>>> "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 truethe AJP/1.3 Connector will not start unless the
> >>>> secret
> >>>>>  attribute is configured to a non-null, non-zero length String.
> >> (markt)"
> >>>>>
> >>>>> Or can i just change this to false? What it its purpose?
> >>>>
> >>>> The purpose of that attribute is to stop you starting up Tomcat with
> an
> >>>> AJP connector that is open to the world without stopping to think
> first.
> >>>>
> >>>> AJP assumes all connecting clients are trusted.
> >>>>
> >>>> You need to make sure that, through the combination of AJP
> >>>> configuration, network configuratiom, etc. that this is the case.
> >>>>
> >>>> If you describe your particular use case, we people on this list
> should
> >>>> be able to provide you with recommended configuration options.
> >>>>
> >>>> 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
>
>


Re: what to do with address="::1"?

2020-02-14 Thread John Larsen
>From my testing.

secretRequired="false" is still needed though docs says its deprecated in
favor of just secret.
I also had to change the worker from host=localhost to host=127.0.0.1

Also AJP13 connector protocol block is commented out where it never was
before.

I'd prefer acceptance of localhost by default and then add secret for
remote ajp servers.

John Larsen

On Fri, Feb 14, 2020 at 7:37 AM Mark Thomas  wrote:

> On 14/02/2020 14:21, John Larsen wrote:
> > I apologize - coffee started to kick in.  The address="::1"  portion is
> > commented out.
> >
> > Will adding  secret="false"? in the server.xml bypass this issue?
> >
> >  > redirectPort="8443" />
>
> That will give you an AJP connector that is only listening on the
> loopback interface.
>
> Mark
>
>
> >
> > Thanks,
> >
> > John Larsen
> >
> > On Fri, Feb 14, 2020 at 6:52 AM Mark Thomas  wrote:
> >
> >> On 14/02/2020 13:45, John Larsen wrote:
> >>> Seems tomcat 9.0.31 has thrown me a curve and messed up my automation.
> >>>
> >>> Where can i understand this change better?
> >>> "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 truethe AJP/1.3 Connector will not start unless the
> >> secret
> >>>  attribute is configured to a non-null, non-zero length String.
> (markt)"
> >>>
> >>> Or can i just change this to false? What it its purpose?
> >>
> >> The purpose of that attribute is to stop you starting up Tomcat with an
> >> AJP connector that is open to the world without stopping to think first.
> >>
> >> AJP assumes all connecting clients are trusted.
> >>
> >> You need to make sure that, through the combination of AJP
> >> configuration, network configuratiom, etc. that this is the case.
> >>
> >> If you describe your particular use case, we people on this list should
> >> be able to provide you with recommended configuration options.
> >>
> >> 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: what to do with address="::1"?

2020-02-14 Thread John Larsen
I apologize - coffee started to kick in.  The address="::1"  portion is
commented out.

Will adding  secret="false"? in the server.xml bypass this issue?



Thanks,

John Larsen

On Fri, Feb 14, 2020 at 6:52 AM Mark Thomas  wrote:

> On 14/02/2020 13:45, John Larsen wrote:
> > Seems tomcat 9.0.31 has thrown me a curve and messed up my automation.
> >
> > Where can i understand this change better?
> > "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 truethe AJP/1.3 Connector will not start unless the
> secret
> >  attribute is configured to a non-null, non-zero length String. (markt)"
> >
> > Or can i just change this to false? What it its purpose?
>
> The purpose of that attribute is to stop you starting up Tomcat with an
> AJP connector that is open to the world without stopping to think first.
>
> AJP assumes all connecting clients are trusted.
>
> You need to make sure that, through the combination of AJP
> configuration, network configuratiom, etc. that this is the case.
>
> If you describe your particular use case, we people on this list should
> be able to provide you with recommended configuration options.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


what to do with address="::1"?

2020-02-14 Thread John Larsen
Seems tomcat 9.0.31 has thrown me a curve and messed up my automation.

Where can i understand this change better?
"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 truethe AJP/1.3 Connector will not start unless the secret
 attribute is configured to a non-null, non-zero length String. (markt)"

Or can i just change this to false? What it its purpose?

Thanks!

John Larsen


Re: Redirecting a naked domain to sub domain

2019-08-06 Thread John Larsen
I usually handle the redirect on the webserver side and set the alias in
server.xml to the subdomain.

John Larsen



On Tue, Aug 6, 2019 at 7:11 AM Simon Funnell  wrote:

> Hi,
>
> I was going to do a redirect at my dns provider from the naked domain to
> the www subdomain. Unfortunatly this doesn't really work if it is over
> https so I am going to have to do the redirect at the host level. My
> question is, is this what the rewrite valve is for? I was going to set up
> two hosts, one for the naked domain and one for the subdomain with a set up
> like the following:
>
>   unpackWARs="true" autoDeploy="true">
>  
>   
>
>  unpackWARs="true" autoDeploy="true">
>
> 
>  directory="logs"
>prefix="localhost_access_log" suffix=".txt"
>pattern="%h %l %u %t %r %s %b" />
>
>   
>
> If this is what the rewrite valve is for, how do I configure it to redirect
> to the subdomain apart from when it accesses the .well-known folder (which
> is needed to get a letsencrypt certificate).
>
> If the rewrite valve is not the correct way to do this do I just deploy a
> catch all servlet or a filter to do the redirect instead?
>
> Thanks,
>
> Simon
>


Re: error 0 issue

2019-06-26 Thread John Larsen
Why windows - especially from 2003. If app is in java you'll get huge
performance boost moving to linux.

John Larsen


On Wed, Jun 26, 2019 at 11:11 AM Kumar R  wrote:

> Hi Team,
> Is it possible to go for higher version of JDK(64 bit) and Tomcat(64bit) on
> 32 bit window 2003 architecture.
> If so, kindly let me know the possible difficulties.
> Thanks
> Rajib
>
> On Tue, Jun 25, 2019, 1:17 AM Kumar R  wrote:
>
> > Hi,
> > Thanks for the help.
> > Thanks & Regards
> > Rajib
> >
> > On Tue, Jun 25, 2019, 1:14 AM Felix Schumacher <
> > felix.schumac...@internetallee.de> wrote:
> >
> >>
> >>
> >> Am 24. Juni 2019 21:23:24 MESZ schrieb Kumar R :
> >> >Hi Team,
> >> >I am facing server 0 issue while starting tomcat 5 service after
> >> >increase
> >> >the heap size from 1024 to 2048.
> >> >
> >> >Server:-
> >> >Windows 32
> >> >Jre:-
> >> >1.5.0_15-h04, mixed mode sharing
> >>
> >> The 32 bit version of Java under windows can't use more than about 1.5
> GB
> >> of ram.
> >>
> >> Note that the versions of Java and tomcat are way out of date. Please do
> >> yourself a favor and update them.
> >>
> >> Felix
> >>
> >>
> >> >Tomcat:-
> >> >5.5
> >> >Error:-
> >> >Jakarta log:- create JavaVM failed, failed initializing java.
> >> >Event log:-
> >> >The Apache Tomcat service terminated with services-specific error
> >> >0(0x0)
> >> >Thanks
> >> >Rajib
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
>


Is there a limit to mod_jk?

2019-04-24 Thread John Larsen
Hello,

Is there a limit to the number of workers instances mod_jk can handle?

I currently have 38 tomcat instances running on a machine. I have had up to
75 in the past, but this machine I keep getting bind exception errors but
lsof -i :port comes up empty when that particular tomcat is offline.

Im at loss as to what is causing it. Usually bind exceptions is when
another java process is running on the same port - but not the case here.
Even if i shutdown apache where mod_jk isnt being used tells me this is
really unrelated to mod_jk

mod_jk.log:
[Thu Apr 25 04:14:07.458 2019] [30178:139932601325312] [error]
ajp_service::jk_ajp_common.c (2796): (w314) connecting to tomcat failed
(rc=-3, errors=2, client_errors=0).
[Thu Apr 25 04:14:07.458 2019] [30178:139932601325312] [info]
jk_handler::mod_jk.c (2991): Service error=-3 for worker=w314

I tried updating mod_jk to 1.2.46


John Larsen


Re: Wildcard certificates

2019-04-17 Thread John Larsen
We do the same - via mod_jk we utilize apache httpd to handle the SSL.
Keeps things simple and works well.
John Larsen

On Wed, Apr 17, 2019 at 7:44 AM TurboChargedDad . 
wrote:

>   We terminated SSL above the tomcat layer using NGINX or Apache to avoid
> the complexities that come with managing a JKS.  I want to hear all I can
> on this subject.
>


Re: What is `tomcat7/common/` for?

2019-03-12 Thread John Larsen
Tomcat 8 uses tomcat/lib instead of tomcat/common/ you'll need to adjust
your script.

John Larsen



On Tue, Mar 12, 2019 at 7:43 AM Joel Griffith  wrote:

> I'm upgrading a webapp server from Tomcat 7 to Tomcat 8 on Ubuntu 16.04.
> At installation, Tomcat 7 creates a directory `/var/lib/tomcat7/common/`.
> When Tomcat 8 is installed, however, the `/var/lib/tomcat8/` directory it
> creates does not include a `common/` directory, and the deployment script
> complains that it isn't there.
>
> build.xml:129: /var/lib/tomcat8/common/lib does not exist.
>
> I've been searching for a day and have found exactly zero documentation on
> this, including on the official 8.0 migration guide (
> https://tomcat.apache.org/migration-8.html).
>
> What is the `/var/lib/tomcat7/common/` directory for, and why does Tomcat 8
> not have one?
>


Re: current best practices for Tomcat with SSL on port 443

2019-02-07 Thread John Larsen
You can use apache with mod_jk and then just setup the ssl through apache
and tomcat will use the 443 port through apache.

If you want to use letencrypt you need to add JkUnMount for /.well-known/*
directory so that when you run lets encrypt it can create and get to this
directory through apache.

John


On Thu, Feb 7, 2019 at 9:45 AM Garret Wilson 
wrote:

> Hi, everyone. In the computer course I'm writing I'm using Tomcat for
> the server. (Students learn how to set up CentOS and everything from
> scratch. Currently the course has them using Tomcat running on port
> 8080.) I'm going back to write the section on security. I want students
> to learn to set up their web server to use SSL/TLS on port 443, with
> HTTP port 80 redirecting to HTTPS port 443. This should be a very basic,
> fundamental configuration, no?
>
> The last time I did this myself was about 10 or 15 years ago, when I
> compiled Apache myself and put it in front of Tomcat using whatever
> connectors (I'll have to go look at my configuration from back then),
> purchasing outrageously priced SSL certificates and installing them
> manually. How I'm sure things are greatly improved. Recently I've set up
> Apache (I didn't have to compile it) hosting static pages directly, and
> using Let's Encrypt (once I figured out what I should be doing) for SSL
> was a breeze. It's working nicely. So I assume I'd want to use Let's
> Encrypt in whatever solution I prescribe to the students.
>
> So what is the best practice, straightforward, and simple setup for
> Tomcat with SSL on port 443 (preferably using Let's Encrypt) with HTTP
> port 80 forwarding to HTTPS port 443? Do I still need to stick Apache
> (or Nginx?) in front of it? (The last I checked, letting Tomcat use
> lower port numbers was a pain, and nobody seemed to know an easy,
> straightforward way to do it.)
>
> Maybe this is a better question of Stack Overflow, but since the experts
> are here and I'm already on the list, I thought I'd ask. Thanks in
> advance! I'm really wanting to learn here.
>
> Best,
>
> Garret
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: HTTP2 with WebSockets

2019-02-06 Thread John Larsen
I am interested in this too. Basically we've had to set another port in
which the app can access tomcat for websockets directly. We've not been
able to get this to work over httpd.
John


On Wed, Feb 6, 2019 at 5:32 PM Jesse Schulman  wrote:

> Is it possible for tomcat to run with HTTP2 and WebSockets on the same
> connector?  I have tried configuring it myself and looked for examples
> without success.
>
> Thanks!
> Jesse
>


Re: Tomcat patch management and patching best practices

2019-02-06 Thread John Larsen
Thats a really good question. We've simply replaced the entire tomcat
installation and then rerun auto config.

Be nice if apache provided patches.

John


On Wed, Feb 6, 2019 at 7:39 PM Murtaza Doctor  wrote:

> Dear Support,
>
> We request your help/advice for the Tomcat Patch Management. We have
> installed Tomcat server to host an application which is internally used in
> our organisation. We donot have any current process/procedure to patch
> Tomcat. So we are looking for your advice on this.
>
> Please address my below queries:
>
> 1) What is the best procedure/practice to keep Tomcat up-to-date with
> patches?
>
> 2) How frequently does Tomcat releases patches/updates? If patches are
> available, please advice the link to access the patches and its details
> (including steps to apply it)
>
> 3) Are separate patches released for security vulnerabilities fixed and bug
> fixed in Tomcat application server?
>
> Kindly advice. Your suggestion will help us in building our internal
> processes. Thanks.
>
> Kind Regards,
> Murtaza Doctor.
>


Re: Proper way to set up tomcat 8.5 (autostart and service setup)

2019-01-08 Thread John Larsen
I simply tie systemd with the init script. Our servers host around 20-30
tomcat instances. I found it easier do it this way.


John Larsen



On Tue, Jan 8, 2019 at 10:26 AM Igal Sapir  wrote:

> On Tue, Jan 8, 2019 at 9:08 AM John Larsen 
> wrote:
>
> > Setup an init script.
> >
>
> On modern Linux systems you should really use systemd instead of the old
> init scripts.
>
> I've written in the past a script that can be used as a systemd template,
> so it allowed for multiple services to be run on different ports with
> different settings.  I can't find it easily ATM though.
>
> I think that it'd be good if Tomcat came with such a script so that it's
> easy to install as a systemd service.
>
> Igal
>
>
> > This is similar to how I do it.
> > https://gist.github.com/katesclau/0ff6e41fd698e94eb43c
> >
> > John Larsen
> >
> >
> >
> > On Tue, Jan 8, 2019 at 10:01 AM Joel Saunders 
> > wrote:
> >
> > > All,
> > >
> > >
> > >
> > > I just installed Tomcat 8.5 on RedHat.
> > >
> > >
> > >
> > > The previous tomcat6 install was setup so that I could use the linux
> > > service command to start and stop.
> > >
> > >   I’d like to take that feature away from the tomcat6
> install
> > > and add it for the new tomcat85 install.
> > >
> > >
> > >
> > > I’d also like for tomcat85 to be able to autostart upon reboots.
> > >
> > >
> > >
> > > Lastly, I’d like the logs to go to /var/log/tomcat8 if possible.
> > >
> > >
> > >
> > > Can anyone point me to the correct way to accomplish these
> requirements?
> > >
> > >
> > >
> > > Thanks in advance for your cooperation.
> > >
> > >
> > >
> > > … Joel
> > >
> > >
> > >
> > > *JOEL SAUNDERS*
> > >
> > >
> > >
> > > SR. DBA/ARCHITECT, MANAGED SERVICES | Zones, Inc.
> > >
> > > W: 518-652-4089| C: 518-265-0771
> > > joel.saund...@zones.com | zones.com <https://nfrastructure.com/>
> > >
> > > <http://zones.com/>
> > >
> > >
> > >
> > > <https://www.facebook.com/nfrastructure/>
> > > <https://www.linkedin.com/company/nfrastructure/>
> > > <https://twitter.com/nfrastructure>
> > > <https://www.youtube.com/user/nfrastructure1992>
> > >
> > >
> > >
> >
>


Re: Proper way to set up tomcat 8.5 (autostart and service setup)

2019-01-08 Thread John Larsen
Setup an init script.
This is similar to how I do it.
https://gist.github.com/katesclau/0ff6e41fd698e94eb43c

John Larsen



On Tue, Jan 8, 2019 at 10:01 AM Joel Saunders 
wrote:

> All,
>
>
>
> I just installed Tomcat 8.5 on RedHat.
>
>
>
> The previous tomcat6 install was setup so that I could use the linux
> service command to start and stop.
>
>   I’d like to take that feature away from the tomcat6 install
> and add it for the new tomcat85 install.
>
>
>
> I’d also like for tomcat85 to be able to autostart upon reboots.
>
>
>
> Lastly, I’d like the logs to go to /var/log/tomcat8 if possible.
>
>
>
> Can anyone point me to the correct way to accomplish these requirements?
>
>
>
> Thanks in advance for your cooperation.
>
>
>
> … Joel
>
>
>
> *JOEL SAUNDERS*
>
>
>
> SR. DBA/ARCHITECT, MANAGED SERVICES | Zones, Inc.
>
> W: 518-652-4089| C: 518-265-0771
> joel.saund...@zones.com | zones.com <https://nfrastructure.com/>
>
> <http://zones.com/>
>
>
>
> <https://www.facebook.com/nfrastructure/>
> <https://www.linkedin.com/company/nfrastructure/>
> <https://twitter.com/nfrastructure>
> <https://www.youtube.com/user/nfrastructure1992>
>
>
>


Re: Accessing the manager application in a new Tomcat 8.5 install

2019-01-07 Thread John Larsen
You need to allow access in your webapps/manager/META-INF/context.xml file

replace

allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1"

with

allow=".*"


Or set it to more restrictive if needed.
Restart tomcat and you should be able to access.

John


On Mon, Jan 7, 2019 at 12:25 PM Joel Saunders 
wrote:

> I’ve spent about 2 weeks on and off (I have other projects) and still cant
> log in to the Tomcat 8.5 manager app.
>
> I get the signon box, enter my credentials from the tomcat-users.xml file
> and the signon box is promptly returned.
>
>
>
> I read the docs regarding the required roles, and the valve that restricts
> access other than from localhost, restarted each time with no success.   I
> haven’t figured out how to set debug on to hopefully give me more info on
> why it’s failing.
>
>
>
> Does anyone have specific steps that would need to be followed in order to
> allow a user to access the manager app after a new install?
>
>
>
> We don’t use this that much so it’s very frustrating to say the least.
> Once I get the manager access handled, then I’ll be able to deploy the
> application that tomcat8 was required for (I know that you can use commands
> vs the gui to do that, but we’re used to using the gui so that’s why we
> need it to work.
>
>
>
> Any comments/suggestions would be greatly appreciated as I’ve already
> wasted way too much time trying to address such a simple request.
>
>
>
> Thanks…
>
>
>
> Joel
>
>
>
> *JOEL SAUNDERS*
>
>
>
> SR. DBA/ARCHITECT, MANAGED SERVICES | Zones, Inc.
>
> W: 518-652-4089| C: 518-265-0771
> joel.saund...@zones.com | zones.com 
>
> 
>
>
>
> 
> 
> 
> 
>
>
>


Re: Tomcat SSL - unsupported protocol or cipher suit error

2019-01-06 Thread John Larsen
I have run into this and solved it.

Basically its due to JDK versions 7 and older.
Two options to fix.
1. upgrade to jdk8
2. Add the following to your JAVA_OPTS or CATALINA_OPTS:
-Dhttps.protocols=TLSv1.2
-Dhttps.cipherSuites=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

John

On Sun, Jan 6, 2019 at 6:39 AM Rajendra  wrote:

> Sameer, can you please share Connector element for ssl port in server.xml
> file?
>
> Also, what is Jdk version you are using?
>
> Thanks !
>
> Rajendra
>
> From: Sameer Umbrajkar
> Sent: 06 January 2019 08:13
> To: users@tomcat.apache.org
> Subject: Tomcat SSL - unsupported protocol or cipher suit error
>
> Dear All,
>
> I am trying to  configure SSL (HTTPS) for Apache Tomcat 8.5.13. I am facing
> below error after importing the certificates.
>
> ==
>
> This page can’t be displayed
>
> Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try
> connecting to *https://localhost:8443  *again. If
> this error persists, it is possible that this site uses an unsupported
> protocol or cipher suite such as RC4 (link for the details)
> , which is not considered
> secure. Please contact your site administrator
>
> ===
>
>
> To generate Key store
> keytool.exe -genkey -alias tomcat -keysize 2048 -keyalg RSA
>
> To generate Certificate request i.e. CSR
> keytool -certreq -keyalg RSA -alias tomcat -file boqa.csr -keystore
> E:\SSL\.keystore
>
> To import chain (intermediate CA)
> keytool -import -trustcacerts -alias intermediate -keystore
> E:\SSL\.keystore -file E:\SSL\MOFChain.cer
>
> To import the signed server certificate
> keytool -import -alias tomcat -keystore E:\SSL\.keystore -file
> E:\SSL\mbq.cer
>
> We did not face error while importing the signed certificates however
> facing TLS protocol/cipher suit related issue now.
> Please help with your insights to resolve the issue
>
> Regards,
>
> Sameer
>
>


Re: Problem with JDK10-12 "NOTE: Picked up JDK_JAVA_OPTIONS"

2019-01-03 Thread John Larsen
How can I surpress it if its not an error? Problem I have is the output
causes the script thinks its an error.

Thanks,

John

On Thu, Jan 3, 2019 at 12:51 PM Mark Thomas  wrote:

> On 31/12/2018 15:12, John Larsen wrote:
> > Hello,
> >
> > Ever since we started using jdk10 and up we get this error message
> whenever
> > we do ./shutdown.sh.
> >
> > NOTE: Picked up JDK_JAVA_OPTIONS:
> > --add-opens=java.base/java.lang=ALL-UNNAMED
> > --add-opens=java.base/java.io=ALL-UNNAMED
> > --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
>
> That is not an error message.
>
> > We need to fix the issue or surpress the output. Any suggestions?
>
> What issue?
>
> That output is generated by the JVM. The options the message refers to
> are set automatically by Tomcat when running on Java 9 or later to
> prevent various features failing (mostly around memory leak detection
> and prevention) due to the additional restrictions added in Java 9.
>
> Mark
>
>
> >
> > There is nothing in catalina.out about this either:
> >
> > 31-Dec-2018 15:09:52.058 INFO [main]
> > org.apache.catalina.core.StandardServer.await A valid shutdown command
> was
> > received via the shutdown port. Stopping the Server instance.
> > 31-Dec-2018 15:09:52.059 INFO [main]
> > org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
> > ["http-nio-8080"]
> > 31-Dec-2018 15:09:52.066 INFO [main]
> > org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
> > ["ajp-nio-8009"]
> > 31-Dec-2018 15:09:52.071 INFO [main]
> > org.apache.catalina.core.StandardService.stopInternal Stopping service
> > [Catalina]
> > 31-Dec-2018 15:09:52.081 INFO [main]
> > org.apache.catalina.core.ApplicationContext.log SessionListener:
> > contextDestroyed()
> > 31-Dec-2018 15:09:52.081 INFO [main]
> > org.apache.catalina.core.ApplicationContext.log ContextListener:
> > contextDestroyed()
> > 31-Dec-2018 15:09:52.090 INFO [main]
> > org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
> > ["http-nio-8080"]
> > 31-Dec-2018 15:09:52.092 INFO [main]
> > org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
> > ["ajp-nio-8009"]
> > 31-Dec-2018 15:09:52.094 INFO [main]
> > org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
> > ["http-nio-8080"]
> > 31-Dec-2018 15:09:52.094 INFO [main]
> > org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
> > ["ajp-nio-8009"]
> >
> > Thanks,
> >
> > John
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: Problem with JDK10-12 "NOTE: Picked up JDK_JAVA_OPTIONS"

2018-12-31 Thread John Larsen
All versions of tomcat. But mostly 8.5 and 9. Also heres my setenv.sh
export JAVA_HOME=/usr/java/jdk11
CATALINA_OPTS="-Xms256M -Xmx256M -server -XX:+UseParallelGC"
export JAVA_HOME CATALINA_OPTS

Thanks

John

On Mon, Dec 31, 2018 at 12:00 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> John,
>
> On 12/31/18 10:12, John Larsen wrote:
> > Ever since we started using jdk10 and up we get this error message
> > whenever we do ./shutdown.sh.
> >
> > NOTE: Picked up JDK_JAVA_OPTIONS:
> > --add-opens=java.base/java.lang=ALL-UNNAMED
> > --add-opens=java.base/java.io=ALL-UNNAMED
> > --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
> >
> > We need to fix the issue or surpress the output. Any suggestions?
>
> Tomcat version?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlwqZzkACgkQHPApP6U8
> pFiQOg//QzYjPfUOKNw2nQ7hKKu+fdmk/TdR9INzKucQqHTunCxdGN2cwKODzyuZ
> b5DwZBTrOTXh5wN6c4cKzIk7LvpMjwMViCLLtbG0TeWBLJCapQATBlVT4D2EWsPr
> IjK1cZg4JkrfnftPRlHzeAjNNsrCHNzcNwZxRYc49xVQpLXUOjrixjlKDCv6vCwh
> 4+CuAwcPu6vkmzPXPkyNmrZRbjHO+TY2nCNyRTlHkx90Xp2MzaL1OWTsS29/UDek
> 7McruCIsEVpt7oS4i6g4dncfxSe4v9sBxE9aQ0XT3ur5dN7AP0jxYqN8kzblwU/s
> KX5/xOcp5lg1DAg4jy1VdMj+e5IPKp2zjn+qm1rWWwtOzbbdhuGQBpwK4UueF0to
> cXEjJMkmyRsSgky3ZllDr8rPr86Q5VTgwIiJQ+Rvnngz/rz3fxaa0jodsZXuvG1Y
> Yf7MBvSx01e5h3qwVL/HJAgVkv+aEkwGPEpsId4uYHHGHkxB6gbaVxZTs5rPkW2T
> e0DNLlu+pc/mhWGp2zRlRp6uW09fygIz5db0FGkMhNYjsbSF3WSmsNXdAt86TWH0
> 4iKdcEkKgfzXph+MUxSqrOzHBvXFvAQ/eVUayBsffvvdhC5CDi+cA5qxkxTxUVRT
> KPWsbapzvuorxwcHkqpo4LxNSVc2KU5cW/zOccYIAolKPcsjlhI=
> =OK4K
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Problem with JDK10-12 "NOTE: Picked up JDK_JAVA_OPTIONS"

2018-12-31 Thread John Larsen
Hello,

Ever since we started using jdk10 and up we get this error message whenever
we do ./shutdown.sh.

NOTE: Picked up JDK_JAVA_OPTIONS:
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/java.io=ALL-UNNAMED
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED

We need to fix the issue or surpress the output. Any suggestions?

There is nothing in catalina.out about this either:

31-Dec-2018 15:09:52.058 INFO [main]
org.apache.catalina.core.StandardServer.await A valid shutdown command was
received via the shutdown port. Stopping the Server instance.
31-Dec-2018 15:09:52.059 INFO [main]
org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
["http-nio-8080"]
31-Dec-2018 15:09:52.066 INFO [main]
org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
["ajp-nio-8009"]
31-Dec-2018 15:09:52.071 INFO [main]
org.apache.catalina.core.StandardService.stopInternal Stopping service
[Catalina]
31-Dec-2018 15:09:52.081 INFO [main]
org.apache.catalina.core.ApplicationContext.log SessionListener:
contextDestroyed()
31-Dec-2018 15:09:52.081 INFO [main]
org.apache.catalina.core.ApplicationContext.log ContextListener:
contextDestroyed()
31-Dec-2018 15:09:52.090 INFO [main]
org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
["http-nio-8080"]
31-Dec-2018 15:09:52.092 INFO [main]
org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
["ajp-nio-8009"]
31-Dec-2018 15:09:52.094 INFO [main]
org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
["http-nio-8080"]
31-Dec-2018 15:09:52.094 INFO [main]
org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
["ajp-nio-8009"]

Thanks,

John