Re: Tomcat 9.0.x on Windows crashing

[Daniel Savard]

Le jeu. 24 août 2023 à 13:06, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> Daniel,
>
> On 8/23/23 13:03, Daniel Savard wrote:
> > I didn't specify the actual Tomcat version because the problem occurs
> under
> > all versions. We are running a commercial web application and all of
> sudden
> > after a while Tomcat is crashing without issuing any message. It is very
> > likely due to the application. But the vendor was of no help to solve
> this
> > problem which has existed for a long time. I suspect something like
> > insufficient memory allocated to the VM or something like that. Is there
> > anything I can do to gather more information on the root cause of this
> > issue?
> >
> > Tomcat is running as a service and is restarted automatically if it
> > crashes. Again, the problem is very unlikely to be with Tomcat itself,
> but
> > the tuning of the VM.
>
> What kind of environment (e.g. Windows vs UNIX, etc.)? What is running
> the service? Are there log files for the service which are different
> than usual (e.g. syslog vs catalina.out)?
>
> What are your memory settings, and how much physical RAM do you have?
>
> It's unlikely that the JVM is just disappearing without leaving any
> trace. If you are on Linux, maybe you are the victim of oome-killer?
> That will show in the syslog with a whole lot of output. Search syslog
> for "oom" and you will probably find it right away if that's the cause.
>
> -chris
>

Hi Chris,

Thanks for the answer.  It is running on Windows and it is running as a
service which is configured to restart if it fails. No different log files
at my knowledge except application logs.

There is 14 GB physical RAM on this server. Initial memory pool is 4 GB and
maximum memory pool is 8 GB.

Well, the only thing I can say is Tomcat is failing at some point and
shutting itself down or being shutdown or killed, I cannot say the JVM
itself gets killed.

-
Daniel Savard

Re: Tomcat 9.0.x on Windows crashing

[Daniel Savard]

Le mer. 23 août 2023 à 13:16, Robert Turner  a écrit :

> You can try adding:
>
> -XX:+HeapDumpOnOutOfMemoryError
> -XX:HeapDumpPath=C:\HeapDump\java_pid.hprof
>
> to the Java options (in "Configure Tomcat") to capture heap dumps on out of
> memory errors (adjust path to suit your configuration)
>
> Robert
>

Hi Robert,

I will look into it. For now, I cannot modify the system easily. I need to
plan a change for this with at least a one week notice and upon approval.
Will try to include this in a forthcoming change.

-
Daniel Savard

Re: Tomcat 9.0.x on Windows crashing

[Daniel Savard]

Le jeu. 24 août 2023 à 02:29, Thomas Hoffmann (Speed4Trade GmbH)
 a écrit :

> Hello Daniel,
>
> > -Ursprüngliche Nachricht-----
> > Von: Daniel Savard 
> > Gesendet: Mittwoch, 23. August 2023 19:03
> > An: users@tomcat.apache.org
> > Betreff: Tomcat 9.0.x on Windows crashing
> >
> > Hi everyone,
> >
> > I didn't specify the actual Tomcat version because the problem occurs
> under
> > all versions. We are running a commercial web application and all of
> sudden
> > after a while Tomcat is crashing without issuing any message. It is very
> likely
> > due to the application. But the vendor was of no help to solve this
> problem
> > which has existed for a long time. I suspect something like insufficient
> > memory allocated to the VM or something like that. Is there anything I
> can
> > do to gather more information on the root cause of this issue?
> >
> > Tomcat is running as a service and is restarted automatically if it
> crashes.
> > Again, the problem is very unlikely to be with Tomcat itself, but the
> tuning of
> > the VM.
> >
> > -
> > Daniel Savard
>
> You can also watch out for a file named hs_err_pid
> If the JVM is crashing hard, it usually produces this file somewhere in
> the Tomcat folder.
>
> Greetings,
> Thomas
>

Thanks for the tip, there is no such file in the whole filesystem. So, the
JVM isn't crashing, but Tomcat is crashing.

-
Daniel Savard

Tomcat 9.0.x on Windows crashing

[Daniel Savard]

Hi everyone,

I didn't specify the actual Tomcat version because the problem occurs under
all versions. We are running a commercial web application and all of sudden
after a while Tomcat is crashing without issuing any message. It is very
likely due to the application. But the vendor was of no help to solve this
problem which has existed for a long time. I suspect something like
insufficient memory allocated to the VM or something like that. Is there
anything I can do to gather more information on the root cause of this
issue?

Tomcat is running as a service and is restarted automatically if it
crashes. Again, the problem is very unlikely to be with Tomcat itself, but
the tuning of the VM.

-
Daniel Savard

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

[Daniel Savard]

Le lun. 13 déc. 2021 à 14:11, Thomas Meyer  a écrit :

> Hi,
>
> Interesting. I know a bit off topic..
>
> Does it make a difference for the vulnerability if I log with:
>
> a) log.warn("log msg param {}", userControlledParam);
>
> Or
>
> b) log.warn(log msg param " + userControlledParam);
>
>
No.


> Mfg
> Thomas
>
>
-
Daniel Savard

Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?

[Daniel Savard]

Thanks, very useful information to channel back to my team and beyond.
-
Daniel Savard

Re: TLSv1.3 Support in Tomcat

[Daniel Savard]

https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites

TLSv1.3 supports 5 cipher suites and none is in your list.

-
Daniel Savard


Le mar. 29 juin 2021 à 01:44, S Abirami  a
écrit :

> Hi Christopher,
>
> Below is my Connector element, sslEnabledProtocols =TLSv1.2 ,TLS 1.3 it is
> working fine with TLSv1.2.  When sslEnabledProtocols=TLSv1.3, Tomcat is
> started but, the browser unable to perform handshake with webapp.
>
> Is there any dependency with Cipher suites?
>
>  protocol="com.ericsson.http.protocol.Http11Nio2ProtocolDecryptProp"
> port="" maxThreads="200" scheme="https" secure="true"
> SSLEnabled="true" keystoreFile="/opt/cert/keystore"
> keystorePass="" clientAuth="false"
> maxHttpHeaderSize="8192" server="" xpoweredBy="false"
> ciphers="TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,
> TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA,
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA"
> sslEnabledProtocols=" TLSv1.3"/>
>
>
>
> Regards,
> Abirami.S
>
> -Original Message-
> From: Christopher Schultz 
> Sent: Monday, June 28, 2021 7:27 PM
> To: users@tomcat.apache.org
> Subject: Re: TLSv1.3 Support in Tomcat
>
> Abirami,
>
> On 6/28/21 07:16, S Abirami wrote:
> > TLSv1.3 support is available in Tomcat.
> >
> > I tried just updating server.xml[sslEnabledProtocols=TLSv1.3] and
> > restarted tomcat. It doesn't work.
> >
> > [We are using Tomcat 9.0.46 and JDK 8u291]
> >
> > Please let me know any other configuration also needs to be changed.
>
> Can you please post your  configuration (minus any secrets)?
>
> When you say "it doesn't work", what exactly do you mean?
>
> -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: Truststore in HTTPS Connector does not work with Linux

[Daniel Savard]

Le jeu. 17 sept. 2020 à 11:31, David Weisgerber 
a écrit :

> I think I was able to figure out the problem (more or less):
> Using two distinct keystores for trusted certificates and server keys
> solves the problem. But don't ask me why there is a difference between
> Windows and Linux on this topic.
> It also does not work to use an empty keystore (on Linux).
>
>
I have one setup among many where the trust and key stores are merged into
a single key store on Linux with Tomcat 8.5.x and it is working just fine.
I don't know why it doesn't work for you and I don't see any reason for
such a behavior.

Regards,
-
Daniel Savard

Re: [OT] Red Hat / CentOS specific question about certificates

[Daniel Savard]

Le lun. 31 août 2020 à 11:13, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> Daniel,
>
> On 8/28/20 20:46, Daniel Savard wrote:
> > Le ven. 28 août 2020 à 17:19, Darryl Philip Baker <
> > darryl.ba...@northwestern.edu> a écrit :
> >
> >> I am having an issue that I don’t understand.  On RHEL6/CentOS
> >> and earlier my predecessors would put self-signed certificates
> >> they wanted to trust in /etc/pki/ca-trust/extracted/java/cacerts
> >> and it was good for the life of the machine. On RHEL7 and I
> >> assume CentOS7 that file is part of a package that is getting
> >> updated as part of the regular patches. That wipes out our
> >> self-signed certificates. The way I understand the directions
> >> from Red Hat we should put the certificate in pem format in the
> >> directory /etc/pki/ca-trust/source/anchors and run
> >> update-ca-trust extract and that will update the all the
> >> appropriate files. Including the cacerts file. That does not seem
> >> to happen. What is the proper way of handling self-signed
> >> certificates you want tomcat to trust?
> >>
> >> Off topic but you are folks who might know: On a related note I
> >> have the same issue with Java applications not running in Tomcat
> >> that use the same file /etc/pki….java/cacerts. Am I
> >> understanding the PKI update process correctly? Am I putting the
> >> self-signed certificate pem format file in the correct place?
> >>
> >> Darryl Baker, GSEC  (he/him/his) Sr. System Administrator (...)
> >>
> >>
> > You can put your certificates and truststore wherever you want as
> > long as you tell Tomcat where they are in the conf/server.xml
> > configuration file when you configure the connector using them.
> >
> > Self-signed certificates should never be used on a production
> > server, they are not secure.
> What makes you say that?
>
> - -chris
> (...)



https://www.venafi.com/blog/self-signed-certificates-cyber-criminals-are-turning-strength-into-a-vulnerability


Never may be exaggerated in my post. But in general, you should avoid them.
But it all depends on your organization as well, mine is signing internal
certificates and managing to include itself in the browsers of all the
thousands employees. In a small business, it may not be possible and the
number of self-signed certificates may be low. In our organization, in the
past we have seen people setting up their own self-signed certificates with
too short keys to be secured by today's standards.

Regards,
-
Daniel Savard

Re: Red Hat / CentOS specific question about certificates

[Daniel Savard]

Le sam. 29 août 2020 à 09:05, Darryl Philip Baker <
darryl.ba...@northwestern.edu> a écrit :

> I will argue that you can use self-signed certificates in production if
> and only if you own and fully control both servers engaged in transaction
> as well as all of the connection fabric between the servers. If these
> conditions are true and someone can execute a man-in-middle attack, I will
> assert that your environment are already so compromised the attack is
> almost meaningless. On the other hand, using a self-signed certificate with
> an expiry of greater than 398 days in a situation as this means that you
> can free up people's time to do other work other than maintaining a hidden
> certificate. And setting up automation to renew said certificate such as
> this, adds an increased level of complexity as well as an additional point
> of failure to the equation.
>
>
> Darryl Baker, GSEC  (he/him/his)
> Sr. System Administrator
> (...)


It all depends on the size of your environment and how you use Tomcat.
Having over 30 servers and thousands of users, self-signed certificates
cannot just be a solution. You have to have each self-signed certificate on
each client accessing the environment to override the security warning
message (in fact, I am not sure it will even go away). Telling your users
to ignore the warning is just not the thing to do since next time they see
the message in another context they may just accept the insecure
connection. And with over 30 servers, automation makes sense for me. Even
for people without the expertise, the Let's Encrypt Certificate Authority
provides short life certificates that are replaced automatically and it
works fine. Getting a properly signed certificate these days is not the
hassle it was, in fact it may just be easier than issuing a self-signed
certificate.

Anyway, it is up to you to decide what you want and if your question is
finally just about what RedHat is doing with that file, you may be better
served on a RedHat discussion list since it ends up being a RedHat only
question having nothing to do with Tomcat itself. From the Tomcat point of
view, you can only copy the file somewhere else where the RedHat scripts,
update procedures will not touch it and let Tomcat know where it is.

Regards,
-
Daniel Savard

Re: Red Hat / CentOS specific question about certificates

[Daniel Savard]

Le ven. 28 août 2020 à 17:19, Darryl Philip Baker <
darryl.ba...@northwestern.edu> a écrit :

> I am having an issue that I don’t understand.  On RHEL6/CentOS and earlier
> my predecessors would put self-signed certificates they wanted to trust in
> /etc/pki/ca-trust/extracted/java/cacerts and it was good for the life of
> the machine. On RHEL7 and I assume CentOS7 that file is part of a package
> that is getting updated as part of the regular patches. That wipes out our
> self-signed certificates. The way I understand the directions from Red Hat
> we should put the certificate in pem format in the directory
> /etc/pki/ca-trust/source/anchors and run update-ca-trust extract and that
> will update the all the appropriate files. Including the cacerts file. That
> does not seem to happen. What is the proper way of handling self-signed
> certificates you want tomcat to trust?
>
> Off topic but you are folks who might know:
> On a related note I have the same issue with Java applications not running
> in Tomcat that use the same file /etc/pki….java/cacerts. Am I understanding
> the PKI update process correctly? Am I putting the self-signed certificate
> pem format file in the correct place?
>
> Darryl Baker, GSEC  (he/him/his)
> Sr. System Administrator
> (...)
>
>
You can put your certificates and truststore wherever you want as long as
you tell Tomcat where they are in the conf/server.xml configuration file
when you configure the connector using them. Self-signed certificates
should never be used on a production server, they are not secure. It is up
to you to handle the certificates when they expire unless you have some
other automated way to renew them. Normally, the cacerts file distributed
with Java is a JKS formatted trust store and the certificates it contains
will eventually expire. That's why when Java is updated you may get an
updated cacerts file as well. If you put your own certificates in that file
and it gets updated when Java is updated, obviously you will lost your
certificates. Just make a copy and put your certificates in the copy. In
fact, you may not need the original file at all if only self-signed
certificates are involved. All the certifications authorities in the file
are then useless to you.

Regards,
-
Daniel Savard

Re: [Tomcat 9.0.37] Https / SSL on Windows server 2016 with windows certificate store

[Daniel Savard]

Le sam. 11 juil. 2020 à 17:52, Valentin  a écrit :

> Hello,
>
> I try to configure my tomcat 9.0.37 installed on a windows server 2016 to
> use a certificate located in *cert:LocalMachine\My*
>
> I mention that I am an administrator of this machine.
> This certificate is also used by IIS.
>
> What I did was to configure my server.xml file like this :
>
>  protocol="org.apache.coyote.http11.Http11NioProtocol"
>SSLEnabled="true"
>maxThreads="150" scheme="https" secure="true"
>keyAlias="myserver.domain.com"
>keystoreFile=""
>keystorePass=""
>keystoreType="Windows-My"
>clientAuth="false" sslProtocol="TLS" />
>
> The error I got in tomcat logs was that the keyAlias doesn't exist but I
> used the CN mentioned in the description of my certificate.
>
> Is it possible for tomcat to use the windows certificate store ?
> The only link I found about this was :
> https://bz.apache.org/bugzilla/show_bug.cgi?id=56021
>
> Thanks for your help
>
> Valentin.M
>

In documentation:
http://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html#Prepare_the_Certificate_Keystore

"Tomcat currently operates only on JKS, PKCS11 or PKCS12 format keystores."

Windows local certificates are stored in the Windows registry.
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/local-machine-and-current-user-certificate-stores

Since IIS is a Windows-only product, this is the simple thing for them to
do. Tomcat runs on various platforms and should support open and neutral
keystore formats instead.

-
Daniel Savard

Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Daniel Savard]

Le mer. 8 août 2018 à 12:08, Louis Zipes  a écrit :

>
> Hi Calder,
> I can successfully start up as a Windows service and get JMX working BUT
> my problem is that Service doesn't stop cleanly (just repeating that
> problem in case it wasn't made clear).  It says the PORT is already in use
> which led me to try to use Catalina_Opts as per the suggestions on the
> internet.
>
> Port already in use: 8008; nested exception is:
>java.net.BindException: Address already in use: JVM_Bind
>
> If you were able to get JMX working and you can start AND stop the Tomcat
> service cleanly, do you mind sharing me your 'scrubbed'  Java tab contents
> as I can seem to get the right combination to get it to Start and Stop the
> service.
>
> Thanks, Louis
>
>
>
Louis,

I believe you need to understand a bit more how things are working with
Java and the JVM. The -D options are pretty straight forward for anyone
knowing how you define properties to the JVM on the command line. I already
told you everything you need to know to setup properly your Tomcat. Since
you were the one talking about CATALINA_OPTS I assumed you did know where
and how to setup the variable for your installation. Otherwise, just go in
the setup utility for Tomcat on Windows and put the
-Dcom.sun.management.conf.file=${catalina.base}/conf/abc.def entry there
without the CATALINA_OPTS= stanza since this one's intent is to set an
environment variable for the process to pick while the former is passing
directly the property to the JVM from the Tomcat Windows Setup dialog.
There is many ways to do things. Bottom line, you need to tell the JVM
where is the configuration file for JMX and put your properties in there as
any other properties file. This is standard stuff.

The effect is the JVM now knows your port is a JMX port and it will stop to
try to use it when it is already in use and free it cleanly.

Regards,

-
Daniel Savard


>
>

Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Daniel Savard]

Le ven. 3 août 2018 à 12:03, Louis Zipes  a écrit :

> Good catch!!  I still had 'd' in front of my lines so once I removed those
> JMX starts up using Management.properties file but as you mentioned it
> doesn't really change the behavior at all and the Service still doesn't
> stop cleanly.  So is there a way to force the JMX to use CATALINA_OPTS in
> this file.  Something like SET CATALINA_OPTS = 'JMX settings'?
>
> That is if the JMX running on CATALINA_OPTS is indeed the answer.
> Basically, trying to mimic the setenv file that is not used by the Window
> Service.
>
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Friday, August 03, 2018 11:52 AM
> To: users@tomcat.apache.org
> Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat
> using a Windows Service in Tomcat 7.0.54
>
> - - - external message, proceed with caution - - -
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Louis,
>
> On 8/3/18 11:32 AM, Louis Zipes wrote:
> > Hi Daniel, I tried your suggestion and while I think it is now
> > acknowledging the existence of the management.properties file
> > (Windows Service wouldn't start if I purposely misspelled
> > 'managemenX.properties') but it doesn't seem to be actually working
> > (JMX can't connect).
> >
> > What I did:
> >
> > I created a copy of an existing logging.properties file already in
> > the CONF folder, renamed it management.properties, and removed all
> > contents of it and put in:
>
> Just FYI, there is nothing magical about an existing properties file.
> It's just a text file with name=value items in it.
>
> > Dcom.sun.management.jmxremote
> > Dcom.sun.management.jmxremote.port=8008
> > Dcom.sun.management.jmxremote.authenticate=false
> > Dcom.sun.management.jmxremote.ssl=false
> > Djava.rmi.server.hostname=
>
> I don't think you want those leading D characters. Is that a
> copy/paste error?
>
> > -Dcom.sun.management.config.file= C:\  > structure>\Tomcat\conf\management.properties
>
> Daniel usually knows what he's talking about, but I'll be surprised if
> Tomcat doesn't fail the same way after making these changes... you are
> just moving the configuration from one place (multiple system
> properties) to another (one system property pointing to another file
> of properties).
>
> - -chris
>

As Christopher said, you this file management.properties can be named
whatever abc.efg would do the same and in that file you have
attribute=value pairs, everything that concerns the com.sun.management.xxx
properties. Then you pass the name of that file as a single option to the
JVM with -Dcom.sun.management.config.file=${catalina.base}/conf/abc.efg and
remove everything else from the CATALINA_OPTS which is in the configuration
file. I strongly suggest to locate this file in the same directory as the
server.xml file and use the ${catalina.base} variable asis and litterally
into the 
CATALINA_OPTS="-Dcom.sun.management.conf.file=${catalina.base}/conf/abc.efg"
definition.

I skipped other configuration files for authentication, in my case I am
authenticating the users against the Active Directory database. So, the
informations I gave for the content of the configuration file is incomplete
and do not necessarily apply to your case, that's why I didn't bother to
put it in my original post. But, you may have to use extra properties for
you particular situation.

Why did I say to put everything in the configuration file for
com.sun.management.config.file? Because that way, the JVM knows these are
for JMX and knows the port is for JMX and will not run into a nonesense
when stopping the service saying the port is already in use. That's why you
should put this into the configuration file and define the property to tell
the JVM the pathname of the configuration file.

Regards,
-
Daniel Savard

Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Daniel Savard]

In ${Tomcat}/conf create the file management.properties and put your stuff
in this file like:

com.sun.management.jmxremote = true
com.sun.management.jmxremote.port = 9876
com.sun.management.registry.ssl =true
com.sun.management.ssl = true
com.sun.management.ssl.enebled.protocols = TLSv1.2
...

Then, remove your stuff from the CATALINA_OPTS and just point to this file
with
-Dcom.sun.management.config.file=${CATALINA_BASE}/conf/management.properties
and you port in use message will disappear since this configuration will be
handled properly.

Regards,

Le 2 août 2018 3:58 PM, "Louis Zipes"  a écrit :

Hi All,
I'm trying to enable JMX monitoring using Tomcat 7.0.54.  Turning on the
JMX monitoring is not the problem. To do this I added the following to the
Apache Tomcat 7.0 Properties 'JAVA' tab  GUI Window, which opens up when
you run 'TOMCAT7w.exe //ES/', and it works in that JMX can
monitor it.

-Djava.rmi.server.hostname=localhost
-Dcom.sun.management.jmxremote.port=8555
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=


The problem is that when I go to STOP the Service it gives me the following
error

Error: Exception thrown by the agent : java.rmi.server.ExportException:
Port already in use: 8555; nested exception is:
   java.net.BindException: Address already in use: JVM_Bind


I have to do a hard kill by either restarting the Appserver or doing SC
QUERY which is not realistic

I can find hits on the error message but the answers seem to relate to the
need to set up JMX under CATALINA_OPTS.  My issue is that I'm struggling to
figure out how to set up CATALINA_OPTS that in Windows when starting Tomcat
using a Service.  The solutions I find either are Linux (I'm Windows) or
talks about setting up JMX with a setenv.bat OR catalina.bat files.
However, from my research the catalina.bat and setenv files are ignored
when you use a Windows Service.

So my question is how do I do I set up CATALINA_OPTS parameter in Tomcat
7.0.54 when I'm using a Windows Service?

Thanks, Louis

---
CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and
may contain information that is confidential, proprietary or exempt from
disclosure. If you are not the intended recipient, please contact the
sender immediately. Unauthorized use or distribution is prohibited and may
be unlawful.

Tomcat 8.5.32 parseHost error

[Daniel Savard]

Hi everyone,

I just upgraded from Tomcat 8.5.23 to 8.5.32 following the required action
on the last CVE issued and I am running into a problem with some
applications. Here is the output from the catalina.out log.

24-Jul-2018 17:02:49.867 INFO [main]
org.apache.catalina.startup.Catalina.start Server startup in 44025 ms
24-Jul-2018 17:02:50.368 INFO [https-jsse-nio-8443-exec-17]
org.apache.coyote.AbstractProcessor.parseHost The host [] is not valid
 Note: further occurrences of request parsing errors will be logged at
DEBUG level.
 java.lang.IllegalArgumentException
at org.apache.tomcat.util.http.parser.Host.parse(Host.java:73)
at org.apache.tomcat.util.http.parser.Host.parse(Host.java:40)
at
org.apache.coyote.AbstractProcessor.parseHost(AbstractProcessor.java:277)
at
org.apache.coyote.http11.Http11Processor.prepareRequest(Http11Processor.java:1203)
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:776)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:800)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1471)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
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)


Any hints on what cause this problem? Is it a configuration issue or a bug?
Anyone else encountered this problem with this version or another one?

Regards,
-
Daniel Savard

Re: how to upgrade tomcat 8.5.x?

[Daniel Savard]

ache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-fr.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-ja.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/tomcat-jdbc.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/tomcat-jni.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/tomcat-util-scan.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/tomcat-util.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/tomcat-websocket.jar
>> ../apps/apache-tomcat-8.5.12/lib
>> cp ./apache-tomcat-8.5.14/lib/websocket-api.jar
>> ../apps/apache-tomcat-8.5.12/lib
>>
>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>


Maybe a useless comment. However I upgraded from 8.0 to 8.5. I have both a
CATALINA_HOME and CATALINA_BASE and the upgrade was really easy and
summarizes almost entierly in changes for the new configuration syntax in
the server.xml file. Upgrading from a release to another is almost a no
brainer, as well as upgrading to a new Java version.

It may be a little more work to start with to setup two separated filetree,
but on the long run, it pays. I have to maintain and support about 70
instances of Tomcat and a dozen of applications as a sideline job.

-
Daniel Savard

Re: Redirection/URL rewriting Tomcat 8.5.14

[Daniel Savard]

Hi Chris,

2017-05-12 13:31 GMT-04:00 Christopher Schultz :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Daniel,
>
> On 5/12/17 10:03 AM, Daniel Savard wrote:
> > Hi everyone,
> >
> > my question is not specific to the Tomcat version specified in the
> > subject line. I am trying to implement a URL rewrite or
> > redirection using Tomcat. What I want to do is the following:
> >
> > In a given instance of Tomcat, I have each application context
> > setup using the xml files in
> > $CATALINA_BASE/conf/[enginename]/[hostname]/, so far so good. Hence
> > for app1 I then have the URL:
> https://myserver:myport/app1, etc.
> >
> > What I need to do, is to have a dummy application which purpose is
> > just to redirect/rewrite the URL from one application to another.
> > So, I need in fact an empty application capturing each request and
> > send back to the browser a rewritten URL to the another
> > application.
> >
> > For example, suppose I want to redirect app1 to app2, I need to
> rewrite all
> > possible URL with query options and so one replacing only app1 by
> > app2 in the URL.
> >
> > https://myserver:myport/app1/something_more_specific?opt1 should be
> >  rewritten as
> > https://myserver:myport/app2/something_more_specific?opt1
> >
> > To do this, I read about the rewrite valve here:
> > http://tomcat.apache.org/tomcat-8.5-doc/rewrite.html
> >
> > So, I created an empty directory $CATALINA_BASE/webapps/app1 with
> > the following file:
> >
> > $CATALINA_BASE/webapps/app1/WEB-INF/rewrite.config
> >
> > And my $CATALINA_BASE/conf/[enginename]/[hostname]/app1.xml has the
> >  following entry within its context:
> >
> >  > className="org.apache.catalina.valves.rewrite.RewriteValve"/>
> >
> > My rewrite.config file is as follow:
> >
> > RewriteCond %{REQUEST_URI} ^/app1/?.* RewriteRule ^/app1(/?.*)$
> > /app2$1 [L]
> >
> > Without anything else, I am getting a HTTP 404 code. With an empty
> >  index.html I am getting a blank page. Within a working application
> > I am getting the application's welcome page. But never the URL is
> rewritten. The
> > rewrite.config file is actually read, I checked by introducing
> > some typo and I am getting an error message at startup.
> >
> > Is there a way to debug this problem? How can I see what is going
> > on with the execution of the rewriting class?
>
> I think everything you have above is correct, except that you want to
> deploy everything in the ROOT application instead of into "app1". With
> "app1", you are re-writing "/app1/app1" to "/app1/app2" when in fact you
> want to rewrite "/app1" to "/app2", correct?
>
> Also, it's important that /app1 not be a deployed application, otherwise
> requests to that context path with be sent to the /app1 application
> instead of to the ROOT webapp.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJZFfGGAAoJEBzwKT+lPKRYlfsQAK9+rFzKtrrPS73Ma9VDclkn
> Lr3oG65TdKPhwVEtQlQoxLggX3GLiepImPzjY52rnMhxCZj+tt5n/fCkqVzEPnIp
> /NNgz/nX/GWqYjU11V58Azh2GRrjBqCJmesawxB/Y5+2NjcW6PrXJNje5PBmkbjs
> QkI5ftAYih7zxWQ4yASJfYwOmmjPpdNfyEM0IR/qkh/VnTz5bVu0/EgeOOK0/Dny
> EsK+3ptm+gdTNVt9jqwEnhWx5tsgpanhTycyyagwROT2A7NaldIi7xARPW3ZlSSF
> 0ncvQ8Z3G0KolBsGsDVyNgNv+bF38sfxOaN7xyp9GXFJVX5hKfRFBphiWPl+jjzz
> mwPcA3MsqDM3fQ4hMTAffmnUAj786pTZ6MCjDnumFjnQZB0zXASEpfI4G9f3+dKM
> fiVdjUQxgrXlUl6wcqBGUidN5PDb+akY8w9xNDl3PvBjrXfFIIfttLgGmxF5cej6
> dkvLqZoitIDzt8dOkWSns3UdK+fq3a1Hjw1BOPlvnvKbnhz2QXrxua6WMDQapohs
> JUUkAR3sujPUs/Tgjq5SiIEBe9sbwQTysNgtw9MzFUmAB7D87cCt0zI8dCbaL54Z
> iYUI0+IDVG7rc7+TwFeRo+ok96qMK1IKCiZt/8pe/097WcWMQq9FeYpGAg4YgZYo
> bwhJFBohEZeuwZCwhN9F
> =J7pC
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Thanks for the tip. I am almost there. Actually, moving everything in ROOT
solved at least the actual execution of the rewriting. However, it didn't
solve entirely my problem.

If I access the URL: https://myhost/app1 in my browser the URL is actually
rewritten to https://myhost/app2 and access the index.html, etc. This is
fine.

However, if I try to access the URL: https://myhost/app1/ in my browser the
URL is NOT rewritten even if the actual application is properly accessed. I
really need the URL to be sent back 

Redirection/URL rewriting Tomcat 8.5.14

[Daniel Savard]

Hi everyone,

my question is not specific to the Tomcat version specified in the subject
line. I am trying to implement a URL rewrite or redirection using Tomcat.
What I want to do is the following:

In a given instance of Tomcat, I have each application context setup using
the xml files in $CATALINA_BASE/conf/[enginename]/[hostname]/, so far so
good. Hence for app1 I then have the URL: https://myserver:myport/app1, etc.

What I need to do, is to have a dummy application which purpose is just to
redirect/rewrite the URL from one application to another. So, I need in
fact an empty application capturing each request and send back to the
browser a rewritten URL to the another application.

For example, suppose I want to redirect app1 to app2, I need to rewrite all
possible URL with query options and so one replacing only app1 by app2 in
the URL.

https://myserver:myport/app1/something_more_specific?opt1 should be
rewritten as https://myserver:myport/app2/something_more_specific?opt1

To do this, I read about the rewrite valve here:
http://tomcat.apache.org/tomcat-8.5-doc/rewrite.html

So, I created an empty directory $CATALINA_BASE/webapps/app1 with the
following file:

$CATALINA_BASE/webapps/app1/WEB-INF/rewrite.config

And my $CATALINA_BASE/conf/[enginename]/[hostname]/app1.xml has the
following entry within its context:



My rewrite.config file is as follow:

RewriteCond %{REQUEST_URI} ^/app1/?.*
RewriteRule ^/app1(/?.*)$ /app2$1 [L]

Without anything else, I am getting a HTTP 404 code. With an empty
index.html I am getting a blank page. Within a working application I am
getting the application's welcome page. But never the URL is rewritten. The
rewrite.config file is actually read, I checked by introducing some typo
and I am getting an error message at startup.

Is there a way to debug this problem? How can I see what is going on with
the execution of the rewriting class?

Regards,
-
Daniel Savard

Re: Can Tomcat act as an HTTPS proxy?

[Daniel Savard]

2017-01-19 12:21 GMT-05:00 David P. Caldwell 
:

> Chris,
>
> Good questions, I'll try to clarify.
>
> 1. The backend server serves files via HTTPS. (I control this, and may
> switch it to HTTP; see below.)
>
> 2. The proxy server has an HTTPS connector like this (but under my
> initial solution I wasn't thinking I should use it).
> (...)
>
> -- David.
>


You just need a web application doing this job. There are many, here is a
link to a short list: https://wiki.apache.org/tomcat/ServletProxy

We have Noodle embedded into another product in production at my shop and
it is working fine so far.

Regards,
-
Daniel Savard

Re: How many instances Tomcat?

[Daniel Savard]

2016-12-16 14:48 GMT-05:00 Edwin Quijada :

> Hi!
> I have 2 different projects in the same server. My server has 16GB Ram and
> 8 core so I am not sure if I need to up 2 instance of Tomcat or just one
> instace and Tomcat server both projects.
>
>
> What is the best configuration ? I have too ApacheWeb Sserver like proxy
> and SSL and virtual server.
>
>
> Any cluees or ideas? Pro and cons about each solution
>
>
> TIA
>
>
It depends on the application. On some of my servers, the application
provider recommend a limit on the number of concurrent connections per
instance. I am even not sure it is justified, however, since we get support
from this provider we have to conform to its directives. However, something
good about having more than one instance is you can shutdown the
application without interrupting the service.

For ressources consumption, you need to look at what your specific
applications need and what kind of workload you expect. Giving the amount
of RAM and the number of cores is useless. I run 9 instances of Tomcat on a
single server with 16 GB of RAM and 2 cores.

Regards,
-
Daniel Savard

Re: TLS/SSL Elliptic Curve support problem with Tomcat 7.0.72

[Daniel Savard]

2016-11-09 16:11 GMT-05:00 Christopher Schultz :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Daniel,
>
> You don't seem to have received a response about this...
>
> On 10/11/16 2:13 PM, Daniel Savard wrote:
> > I have a problem which evades me for a too long time. I am just
> > unable to find out what is wrong. I have a Tomcat 7.0.72 (version
> > doesn't matter the problem exists with 7.0.68 and 7.0.70 as well)
> > with Oracle JDK 1.8.0_102 (the version doesn't matter much neither
> > since the problem manifests with 1.8.0_92, 1.8.0_77 as well).
> >
> > My Tomcat is unable to complete its TLSv1.2 handshaking protocol. I
> > am getting this in my log when enabling SSL debug:
> >
> > [snip]
> >
> > The key message seems to be: Extension elliptic_curves, curve
> > names: {unknown curve 29,
> > java.security.spec.ECParameterSpec@2b839e7c,
> > java.security.spec.ECParameterSpec@55e0b1ed}
>
> That seems okay to me: Java understands 2 of the 3 curves supported by
> the client. Curve 0x19 is secp521r1 which is not mentioned by the NSA
> Suite B publication, so it's often not implemented.
>
> > I should get something with a list of recognized curves.
>
> It looks like 2 of them are recognized.
>
> > Later, when the server will complete the handshaking with a fatal
> > error, it will obviously fail agreeing on the curve and share
> > parameters. Like this:
> >
> > -
> >
> > ** ECDH ServerKeyExchangeSignature Algorithm
> > SHA512withRSAServer key: com.rsa.cryptoj.o.fn@a9c1e230***
> > ServerHelloDone
> >
> > --
>
> It "will", or it /does/?
>
> > Where I should get the name of the curve and the parameters for the
> > shared secret.
>
> If the runtime doesn't implement the curve, you can't use it. The
> question is why the client and the server won't use the two curves
> they *do* agree on.
>
> Which client is this? Many clients (e.g. Google Chrome, MSIE/Edge)
> don't support curve #19. I use Mozilla Firefox, which currently does
> support curve #19. Does your TLS site work with Firefox? Apple Safari
> also supports curve #19.
>
> > Since I have some other instances on the same server running just
> > fine. I wonder what I should look for. What can lead to this
> > failure?
> >
> > Yes, I have the Unlimited JCE Policy installed and working for
> > other instances of Tomcat 8. Both Tomcat 8 and Tomcat 7 on this
> > server share the very same JDK.
>
> The JCE security policy probably isn't affecting this.
>
> > In the Firefox browser, the message is as follow: Unsupported
> > elliptic curve. Error code: SEC_ERROR_UNSUPPORTED_ELLIPTIC_CURVE
> > Which is the most descriptive message among the three following
> > browsers: IE 11, Chrome and Firefox. IE11 and Chrome are
> > complaining about TLS protocol error without saying anything about
> > the cause of the error.
>
> Can you post your  configuration?
>
> - -chris
>

 Hi Chris,

thanks for replying. I struggled a while with this problem to find out (I
wasn't able to append a comment to let people know) the application seems
to behave oddly. I don't have the source code for this application, it is a
commercial application and it requires some file for encryption purpose.
Usually, we are using the default. But it seems someone else decide to
tamper with this file and changed it for another one which seems to make
the application change the JVM JCE setup somehow. Anyway, I didn't
investigated further after I discovered restoring the old file makes the
problem disappear. I missed that file when I scanned the webapps filesystem
and compared the checksum file by file with a working environment because
that specific file is located outside the webapps filetree. The file itself
is encrypted/encoded, so I can't easily check the content and didn't invest
time to find out anyway.

Regards,
-
Daniel Savard

Re: Tomcat clustering and FarmDeployer

[Daniel Savard]

Le 20 oct. 2016 3:21 PM, "André Warnier (tomcat)"  a écrit :
>
> Maybe naive, and I have never tried any of this myself, but is there a
reason why you cannot use method 2 in
>
http://tomcat.apache.org/tomcat-8.0-doc/deployer-howto.html#A_word_on_Contexts
> in that scenario ?
>

Thanks, tested for my needs and it's working fine. I had to change one
minor thing in my approach.

Re: Tomcat clustering and FarmDeployer

[Daniel Savard]

2016-10-20 15:16 GMT-04:00 André Warnier (tomcat) :

Maybe naive, and I have never tried any of this myself, but is there a
> reason why you cannot use method 2 in
> http://tomcat.apache.org/tomcat-8.0-doc/deployer-howto.html#
> A_word_on_Contexts
> in that scenario ?
>
>
André,

thanks I will give it a try. I never used method 2 before and I just forgot
about it.

-----
Daniel Savard

Tomcat clustering and FarmDeployer

[Daniel Savard]

Hi everyone,

I am testing the FarmDeployer in a Tomcat cluster environment and it seems
it cannot do what I would like it to do.

So far, it works fine to deploy the web application on all cluster members.
However, the way they are deployed is the plain war file drop into the
appBase directory. I didn't find any way to make it working with a context
specific to the application configured in the ${ENGINE}/${HOST}/appName.xml
file for example for the appName web application.

Anyone knows if there is a trick to do that? Or is there a reason it is not
possible to associate a context specific to the web application?

BTW, if it is of any use, I am running Tomcat 8.0.36 and Oracle JDK
1.8.0_92.

Regards,
-
Daniel Savard

TLS/SSL Elliptic Curve support problem with Tomcat 7.0.72

[Daniel Savard]

Hi tomcaters,


I have a problem which evades me for a too long time. I am just unable to
find out what is wrong. I have a Tomcat 7.0.72 (version doesn't matter the
problem exists with 7.0.68 and 7.0.70 as well) with Oracle JDK 1.8.0_102
(the version doesn't matter much neither since the problem manifests with
1.8.0_92, 1.8.0_77 as well).

My Tomcat is unable to complete its TLSv1.2 handshaking protocol. I am
getting this in my log when enabling SSL debug:

---

*** ClientHello, TLSv1.2RandomCookie:  GMT: -1507805229 bytes = { 111,
107, 93, 180, 22, 176, 151, 182, 118, 207, 100, 218, 44, 244, 231,
167, 14, 64, 248, 62, 57, 126, 137, 35, 76, 84, 30, 245 }Session ID:
{}Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, Unknown 0xcc:0xa9, Unknown
0xcc:0xa8, Unknown 0xcc:0x14, Unknown 0xcc:0x13,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA,
SSL_RSA_WITH_3DES_EDE_CBC_SHA]Compression Methods:  { 0 }Extension
renegotiation_info, renegotiated_connection: Extension
server_name, server_name: [type=host_name (0),
value=hostname.domainname.tld]Unsupported extension type_23,
data:Unsupported extension type_35, data:Extension
signature_algorithms, signature_algorithms: SHA512withRSA,
SHA512withECDSA, SHA384withRSA, SHA384withECDSA, SHA256withRSA,
SHA256withECDSA, SHA1withRSA, SHA1withECDSAUnsupported extension
status_request, data: 01:00:00:00:00Unsupported extension type_18,
data:Unsupported extension type_30032, data:Extension
ec_point_formats, formats: [uncompressed]Extension elliptic_curves,
curve names: {unknown curve 29,
java.security.spec.ECParameterSpec@2b839e7c,
java.security.spec.ECParameterSpec@55e0b1ed}***%% Initialized:
[Session-1, SSL_NULL_WITH_NULL_NULL]%% Negotiating:  [Session-1,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]*** ServerHello, TLSv1.2

--

The key message seems to be: Extension elliptic_curves, curve names:
{unknown curve 29, java.security.spec.ECParameterSpec@2b839e7c,
java.security.spec.ECParameterSpec@55e0b1ed}

I should get something with a list of recognized curves. Later, when the
server will complete the handshaking with a fatal error, it will obviously
fail agreeing on the curve and share parameters. Like this:


-

** ECDH ServerKeyExchangeSignature Algorithm SHA512withRSAServer
key: com.rsa.cryptoj.o.fn@a9c1e230*** ServerHelloDone

--

Where I should get the name of the curve and the parameters for the shared
secret.

Since I have some other instances on the same server running just fine. I
wonder what I should look for. What can lead to this failure?

Yes, I have the Unlimited JCE Policy installed and working for other
instances of Tomcat 8. Both Tomcat 8 and Tomcat 7 on this server share the
very same JDK.

In the Firefox browser, the message is as follow: Unsupported elliptic
curve. Error code: SEC_ERROR_UNSUPPORTED_ELLIPTIC_CURVE
Which is the most descriptive message among the three following browsers:
IE 11, Chrome and Firefox. IE11 and Chrome are complaining about TLS
protocol error without saying anything about the cause of the error.

Any hints?

Regards,

-----
Daniel Savard

Re: Tomcat 8 HTTPS issue with old browser

[Daniel Savard]

Your challenge is much more with Java 8 as already mentioned above if you
use a non-APR connector and with OpenSSL otherwise than with Tomcat itself.

-
Daniel Savard

2016-10-04 6:43 GMT-04:00 Garratt, Dave :

> To elaborate, there is only this single application running on the server.
> All other web applications use Windows IIS.
>
> I have mentioned that the problem is down to the old software on the
> scanner but it’s a huge international organisation and making a upgrade to
> their entire line of devices is likely to take some time.
>
> However silly it may seem this is a “tick the box” exercise when it comes
> to security - HTTPS - yes/no.
>
> On the assumption that a weak encryption is better than none then I can’t
> really argue with the customer.
>
> Someone did suggest using Apache HTTP server to do the comms - maybe and
> IIS connector to Tomcat would accomplish the same ?
>
> As I mentioned before I’m a bit of a novice with the server config.
>
> Dave
>
>
> > On 4 Oct 2016, at 11:29, André Warnier (tomcat)  wrote:
> >
> > On 04.10.2016 09:53, Garratt, Dave wrote:
> >
> >>> On 4 Oct 2016, at 08:48, André Warnier (tomcat)  wrote:
> >>>
> >>> On 04.10.2016 09:38, Garratt, Dave wrote:
> >>>> I have Apache Tomcat 8 working ok with https when I connect to my web
> page using a recent browser (desktop) or iPhone for example. However this
> specific application is designed to run on a Motorola MC9090 hand held
> wireless barcode scanner running a relatively old version of Windows
> Mobile. The browser on that device can only load the HTTP page and not the
> HTTPS page, giving a unable to open page message. Speaking to a “expert” on
> these scanners the consensus of opinion is that the type of encryption used
> by Apache Tomcat 8 is more up to date than the mobile devices browser can
> support. As it does not appear likely that the mobile devices are going to
> be updated any time soon I was wondering if its possible to force Tomcat to
> accept deprecated protocols rather than be forced to revert to plain HTTP.
> >>>>
> >>>> Any ideas or ideally an example of how this might look in a config
> file would be most appreciated.
> >>>>
> >>>>
> >>>
> >>> Naive question : if you are dealing anyway with old devices that
> cannot be replaced by new devices, then why do you not just keep using the
> correspondingly old version of tomcat and of the JVM ?
> >>>
> >>>
> >
> >> The requirement for HTTPS is only a recent requirement and the
> application is now heavily dependent on Java 8. At this point I don’t know
> just how old a version of Tomcat I would need to make it work and I would
> have to make significant changes to the code in order to make it Java 6/7
> compliant.
> >>
> >
> > I was just wondering, basically because the reason for retiring an old
> SSL protocol is usually that it has been proven insecure and/or buggy. So,
> there might be a way to do what you are requesting, but it does not seem to
> make sense that the requirement for HTTPS is recent (and presumably linked
> to a wish for increased security), yet for these old devices the only way
> to do it, would be by enabling and old/buggy SSL protocol (and thus
> potentially weaken other applications running on the same host). There
> seems to be a bit of a logical thinking contradiction in this, no ?
> >
> > To dig a bit deeper : there are two families of "connectors" which can
> be used by Tomcat :
> > - the ones based on the underlying Java JVM's SSL
> > - the one based on the underlying APR (Apache Portable Runtime), which
> use OpenSSL-based logic
> >
> > If you wanted to enable an old deprecated protocol under the Java 8 JVM,
> you'd have to look if this old protocol is even still supported by the Java
> 8 JVM. If not, though luck, because the chances of persuading the vendor of
> this JVM to change their ways are probably slim to say the least.
> > If you wanted to enable an old deprecated protocol in the APR-based
> connectors, your chances may be a bit better (but not guaranteed), to find
> a working combination of Tomcat/APR/OpenSSL which allows this and still
> works. But as time goes on, these things will eventually get upgraded, and
> your old devices may get the problem again at some unexpected moment.
> > You may also be facing issues then, if some security team scans your
> server, and finds out that it is allowing a deprecated HTTPS protocol
> (which would show up even for accesses having nothing to do with this
> application or these devices).
> >
> >

Re: TLS 1.2 Handshake on Tomcat 7.0.39 Getting Internal Error: Key format must be RAW

[Daniel Savard]

2016-09-22 6:16 GMT-04:00 André Warnier (tomcat) :

> Dono,
>
> Ok, this is  really a long shot, and I really do not know what I am
> talking about..
>
> I just want to point out that in the course of doing some searches on the
> WWW with keywords related to your issue, I seemed several times to come
> across articles which were referring to some restrictions in Java
> cryptography, having to do with US export regulations (cryptography being
> an area submitted in part to such rules).
> In my limited understanding, the apparent gist of it seemed to be that
> - for systems based in the US, by default some java-cryptographic modules
> allow some encryption methods (or key strengths etc.)
> - while for non-US-based systems some of these methods/strengths are by
> default disabled
> To re-enable these methods, one has to either change some java parameters
> (at the risk of falling foul of said export restrictions), or replace some
> standard underlying libraries, by other similar ones developed outside of
> the US.
> And, in some cases, such "similar" libraries may throw exceptions where
> the standard ones would not.
> All of the above to take with a grain of salt, considering my almost total
> lack of knowledge in the matter.
> But, considering that your production system may be one case, and your
> staging systems another, and considering that so far nobody seems to have
> found the ultimate answer to your problem, this could be an area to
> investigate.
>
> I will make another wild guess : a lot of people on this list probably
> either work predominantly on US-based systems, or don't know about such
> restrictions, or are unfamilar with them, and for such reasons have
> probably never encountered the kind of issue which you mention.  So it is
> probably no wonder that everyone seems to be a bit in the dark (including
> myself).
>
>
Not exactly that. By default, Java is shipped or distributed without the
Unlimited Strength Policy Files (you have to replace 2 jar in
jre/lib/security). The reason they are not installed by default being they
are not legal everywhere. If it is legal in your country, you can simply
install them and you have exactly the same libraries and algorithms as
those who are having by default an unrestricted installation. For Oracle
JDK 1.8, you can download the files from this URL:
http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html

I have many Tomcat instances doing TLSv1.2 without problem. I only
encountered problems with Tomcat 7 on one server for a still unknown reason
and very unlikely related to Java itself.

I have over 70 Tomcat instances all running TLSv1.2 and in usage daily
7/24. I am using the Unlimited Strength Juristiction Policy Files for Java
8.

Regards,

Re: tomat8.5 write logs with incorret os permission

[Daniel Savard]

To me, it appears as false problem. I don't see why the change to the
permissions on the log file is so critical for the security. You can simply
set appropriately the permissions on the directory where the log files are
written if you don't want anyone to look at them. You can use ACL if your
OS support them. You can use umask to change the default behavior.

If security of log files is critical for your application, you should take
time to design the logging appropriately and don't expect someone else to
take care of all your concerns for you.


---------
Daniel Savard

2016-08-05 7:24 GMT-04:00 André Warnier (tomcat) :

> Hi.
>
> On 05.08.2016 08:00, 韭菜 wrote:
>
>> Definitely a bad idea to relax the default permissions back to where they
>>> were.  If you want to expose your own system to abuse, you can set umask as
>>> documented in the changelog.
>>>
>> Is there a way to like config some param to force tomcat write logs in
>> old way ?and could you please give me a doc url about how set umask for
>> tomcat run user ？
>>
>>
> You might want to start here :
>
> http://lmgtfy.com/?q=linux+umask+command
>
> Then, you may need to find out which command or shell script, *on your
> Linux system*, is starting Tomcat, and insert the desired umask command
> there.
>
> But please consider the remarks made previously by Chuck.
> Logfiles may contain information which you do not want to disclose to
> other than a system administrator.  By making these files widely readable,
> you weaken the security of your whole server and perhaps much more.
>
> Be aware also, that by setting the umask for the Tomcat process, you are
> influencing the permissions of *any* file which Tomcat itself, or any
> Tomcat webapp would create.
>
>
>
>>
>>
>> -- Original --
>> From: "Caldarale, Charles R";
>> Date: 2016年8月5日(星期五) 中午12:25
>> To: "Tomcat Users List";
>> Subject: RE: tomat8.5 write logs with incorret os permission
>>
>>
>>
>> From: 韭菜 [mailto:jiu...@qq.com]
>>> Subject: tomat8.5 write logs with incorret os permission
>>>
>>
>> When using tomcat8.0, it starts and write logs as follows:
>>> (apache-tomcat-8.0.x) -rw-rw-r-- 1 app app 873710 Aug  4 20:08
>>> catalina.log
>>> When using tomcat8.5.x (include tomcat 9.0.x), it starts and write logs
>>> as follows:
>>> (apache-tomcat-8.5.4) -rw-r- 1 app app 100824 Aug  4 20:10
>>> catalina.log
>>>
>>
>> A highly appropriate change, much needed to prevent untrusted users from
>> accessing private information in the log.
>>
>> So, tomcat8.5 caused other os users can not read its logs and webapps
>>> logs that deployed
>>> at tomcat8.5. the logs files should has permission 664, not 640.
>>>
>>
>> Definitely not a good idea.
>>
>> I thinks it is not good for java webapp devlopers ,  when my web app
>>> write logs as
>>> data log, the logs files can not rsync by other users and hosts.
>>>
>>
>> As it should be.
>>
>> but it works at tomcat7.0.x and tomcat8.0.x
>>>
>>
>> "Works" is your definition; any site interested at all in secure
>> operations would consider the old permissions to be dangerous and broken.
>>
>> So I asked users to require further support for tomcat8.x write log files
>>> feature.
>>>
>>
>> Definitely a bad idea to relax the default permissions back to where they
>> were.  If you want to expose your own system to abuse, you can set umask as
>> documented in the changelog.
>>
>>   - Chuck
>>
>>
>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
>> MATERIAL and is thus for use only by the intended recipient. If you
>> received this in error, please contact the sender and delete the e-mail and
>> its attachments from all computers.
>>
>>
>> -
>> 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: Facing issue while configuring SSL

[Daniel Savard]

2016-07-14 4:38 GMT-04:00 Devendra Sengar :

> If i am giving the full path of the certificate like
> c:/tomcat/conf/ then its taking the file, as the error i was
> getting "SEVERE: Failed to initialize end point associated with
> ProtocolHandler ["http-apr-443"]" that's no more.
>
> But the tomcat server is started without any error but won't able to open
> the home page of tomcat giving the error like:
> This site can’t be reached
> The webpage at *https://:8443/* might be temporarily down or it
> may have moved permanently to a new web address.
>
> If i telnet the server then its not able to connect but if i use openssl
> s_client -connect it shows the certificate information.
> Any suggestion?
>
>
Yes, specify the path as ${catalina.base}/conf/ since your file
seems to be in the conf directory of your Tomcat instance. I'm not sure
about the C: in the pathname. However, ${catalina.base}/conf/ is
portable and enables you to move you instance into another directory
without having to modify all the configuration files.

-
Daniel Savard

Re: Need help setting up SSL on Tomcat 8

[Daniel Savard]

2016-07-13 15:56 GMT-04:00 Sean Son :

> Thank you for your answer guys. Is there anywhere in the Tomcat config
> files that I would need to specify the DNS name?  Like in Apache we would
> specify the DNS name in a Virtualhost.
>
>
No.

---------
Daniel Savard

Re: Need help setting up SSL on Tomcat 8

[Daniel Savard]

2016-07-12 14:34 GMT-04:00 Sean Son :

> Are there any logs on the tomcat server that I should check in order to fix
> this SSL issue? or is this strictly a certificate related issue?
>

At my opinion, it is a DNS issue. Your certificate specify the
SubjectAlternativeName field with two DNS entries. If none of these can be
resolved for your server, the certificate is considered invalid.

-----
Daniel Savard

Re: Need help setting up SSL on Tomcat 8

[Daniel Savard]

2016-07-07 14:53 GMT-04:00 Sean Son :

>
>
> On Thu, Jul 7, 2016 at 12:24 PM, Sean Son <
> linuxmailinglistsem...@gmail.com> wrote:
>
>> Copying Daniel and Ognjen on this
>>
>> On Thu, Jul 7, 2016 at 12:02 PM, Sean Son <
>> linuxmailinglistsem...@gmail.com> wrote:
>>
>>> Hello
>>>
>>>  I tried adding the keyAlias to the connector and when i restarted
>>> Tomcat, and i browsed to the sever page, I got this error:
>>>
>>> Certificate Error
>>> There are issues with the site's certificate chain
>>> (net::ERR_CERT_COMMON_NAME_INVALID).
>>>
>>> Looks like adding the keyAlias to the connector did not fix anything
>>> unfortunately.
>>>
>>
>
Did you examined the received certificate in the browser. Usually this help
to identify why it failed. In this case, the chain of certification seems
to be the problem.

-
Daniel Savard

Re: Need help setting up SSL on Tomcat 8

[Daniel Savard]

2016-07-07 10:52 GMT-04:00 Sean Son :

> So I should modify my  connector to look like this?
>
>  protocol="org.apache.coyote.http11.Http11NioProtocol"
>maxThreads="150" keystoreFile="conf/tomcat.jks"
> keystorePass="password" keyAlias="{b81d8607-57e9-4c35-a058-cd46099e7797}"
> SSLEnabled="true" scheme="https" secure="true"
>clientAuth="false" sslProtocol="TLS" />
>
>
Yes.

-
Daniel Savard

Re: Tomcat 7 and SHA-1

[Daniel Savard]

2016-07-01 16:21 GMT-04:00 Christopher Schultz :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Greg,
>
> On 7/1/16 3:03 AM, Greg Beresnev wrote:
> > Thanks Daniel - any idea which cipher in particular needs to be
> > absent in order for the SHA-1-based connection/authentication was
> > rejected/failed?
>
> I'm afraid Daniel may have confused the issue, because the
> certificate-signing algorithm is completely independent of any cipher
> suites that you may use for the encrypted TLS connection.
>
> FWIW, at $work, we typically filter-out anything that looks like this:
>
> NULL|_anon_|_DHE_|EXPORT|RC4|MD5|SHA$
>
> But there's no way I know of to reject the local server certificate if
> it doesn't meet some kind of criteria.
>
> I checked, and Nagios's check_http utility does NOT have a check for
> anything about a certificate other than it's expiration date. This
> seems like a good thing to add to that tool (along with complaining
> about support for certain protocols like SSLv3).
>
> There are other tools you could use, such as Mark's suggestion of
> using Qualys's ssltest site.
>
>
In fact, to enforce SHA-2 (which is the same as SHA-256) you just have to
switch to TLSv1.2 and nothing less. As per the RFC 5246
https://tools.ietf.org/html/rfc5246 SHA-2 is mandatory, paragraph 1.2.

Chris, you are right, the cipher suite is something different from the HMAC
for the certificate itself. However, if the user wants to ban the SHA-1
from the negociated symmetric encryption algorithm, he will have to set a
proper cipher suite to exclude anything without SHA-256 and more from the
accepted ciphers. You have to experiment with the openssl cipher command to
find out a proper combination.

-
Daniel Savard

Re: Need help setting up SSL on Tomcat 8

[Daniel Savard]

2016-07-01 16:08 GMT-04:00 Christopher Schultz :

>
> >
> > Thank you for the reply.  How would I go about specifying the alias
> > of the certificate?
>
> You may have to re-import it, but I've had bad experiences with Java
> keystores so ALWAYS keep a backup in case you host something.
>
> The first item in your keystore certainly looks like a certificate to
> me. It's the *second* item that is a private key.
>
> What if you add these attributes to your connector:
>
> keyAlias="root"
>
> ?
>
> If that doesn't work, try using a tool like Portecle to try to adjust
> some things (like the "aliases"). It's much better and safer than
> using keytool IMO. Remember ALWAYS KEEP A BACKUP!
>
>
Chris,

in a keystore, the entry with the certificate created using the private key
from that keystore is a single entry identified as PrivateKey. If you have
a single certificate created from a private key in that keystore you will
have only one entry, not two and it will be labeled as private key.

In fact, it can be checked using the -v option to print details about each
entry. This should be enough to identify without ambiguity which entry is
what. This is what I recommend to do in order to understand what really is
in the keystore. I doubt the alias root with the first entry in the
keystore is actually the certificate needed here.

Sean,

print the details and you will have the alias and Common Name clearly
identified on the output in a verbose format. Use the -v option to the
keytool command for this. No need to post everything here if you are unsure.

-
Daniel Savard

Re: Need help setting up SSL on Tomcat 8

[Daniel Savard]

2016-06-29 9:08 GMT-04:00 Sean Son :

> Hello Daniel
>
> Thank you for the information. Here is the output of the keytool command:
>
> Keystore type: JKS
> Keystore provider: SUN
>
> Your keystore contains 2 entries
>
> root, Jun 16, 2016, trustedCertEntry,
> Certificate fingerprint (SHA1):
> 27:AC:93:69:FA:F2:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8
> {b81d8607-57e9-4c35-a058-cd46099e7797}, Jun 16, 2016, PrivateKeyEntry,
> Certificate fingerprint (SHA1):
> 6C:67:52:63:6B:EF:A2:3D:CD:A7:CB:64:99:99:4F:9C:3E:85:B9:AA
>
>
> Is it possible that the error that I am seeing, is related to the fact
> that I am using a wildcard certificate?
>

So, the first entry in the keystore isn't your certificate. As I told you
before, if you do not specify explicitely the alias of the certificate so
send, the first entry in the keystore is sent. In this case, root.

The attribute to tell the connector which certificate to send, is keyAlias,
however it seems your certificate has no alias in the keystore.

-
Daniel Savard

Re: Tomcat 7 and SHA-1

[Daniel Savard]

  2016-06-30 23:05 GMT-04:00 Greg Beresnev :

> Hi,
>
> We're in the process of updating our web application to stop using SHA-1
> certificates and I was wondering if there was some way to configure Tomcat
> (we're on version 7.0.39 - yes, I know, we are pretty old-school and should
> get with the times) to either throw errors or at least log warnings for the
> cases where connection/authentication attempt is being made using SHA-1
> certificate?
>

No.

However, you can select the accepted ciphers to reject anything that
doesn't meet your standards.

-
Daniel Savard

Re: Need help setting up SSL on Tomcat 8

[Daniel Savard]

2016-06-28 16:24 GMT-04:00 Sean Son :


>
> as for the output to the keytool command:
>
> Isnt the output to that command, confidential information?
>
>
No, there isn't anything confidential from the output of a simple -list. It
doesn't display the private key or anything like that. It will  just show
the list of certificates in your keystore.

The first entry in the keystore will be the one sent back by the Tomcat
server since you didn't specify any alias. So, I assume this is the
intended behavior.

Since you do not specify any trust store, the default trust store shipped
with your version of Java will be used. If the clients trying to connect
are not having certificats signed by one of these, it will fails. It may
not be a problem in your case since you do not provide any details on the
clients' certificates.

Regards,
-
Daniel Savard

Re: Configuring Tomcat to support TLSv1.2

[Daniel Savard]

2016-06-24 11:50 GMT-04:00 Joleen Barker :

> Hi Chris,
>
> The SSL_VERSION parameter was already defined by the vendor.
>
>
I still would delete the SSL_VERSION from the catalina.sh or comment it at
least and adopt the suggested approach to configure everything in the
server.xml file instead. Without a specific definition of the SSL_VERSION,
there will be no constraints on the versions at this point. This
SSL_VERSION environment variable will bite you when you will need to
upgrade Tomcat to another version.


> The web application we use allows users to connect to it via FTP, FTPS,
> SSH, AS2, HTTPS, HTTP, etc. to transfer files through it to different back
> end servers. The web application is a proxy.
>
> Without me making the change to the predefined SSL_VERSION parameter that
> was originally configured as "-Dhttps.protocols=TLSv1" to now be configured
> to
> "-Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2" (thank you for correcting my
> typo) our remote party that uses and AS2 client that is locked down to only
> using TLSv1.2 connection could now connect to us successfully and upload a
> file. So with this change I was able to accomplish the client to connect to
> the Tomcat server. But I am unable to accomplish a successful connection
> when Tomcat is acting as the client to reach the remote AS2 server for us
> to send a file to them. It appears we are not connecting to them using
> TLSv1.2 and therefore we are dropped. I have a ticket open with the vendor
> on this but they don't seem to be any help. I was trying to open the Java
> console on the UNIX server but I am unable to as I do not have any X11
> setup. I am unable to find a command line option to set what is allowed in
> the Java application itself. On one of our test servers a colleague could
> open the console and we saw that none of the TLS options were NOT enabled
> and only SSLv3 was. I am not sure if this is the case with this server that
> I am working on that we have an outside connection open to be able to work
> with the outside customer.  I am unsure if this change would allow us to
> reach them. I didn't know what the catalina.sh TLSv1.2 change versus
> changing the Java application TLSv1.2 change is really responsible for. (I
> know enough to brake stuff...lol) The vendor is not much help. It's very
> frustrating so I reach out to this community and get the help I need.
>
>
The connection that isn't working is initiated by the web application on
your Tomcat server as far as I understand. If so, then there is no
configuration at the Tomcat level that will resolve this issue. You must
look at the SSL debugging info to see what is going on in the negotiation
with the remote party. To do that, use the -Djavax.net.debug=ssl option to
the JVM and look at the log files (probably catalina.out) You should see
the handshaking protocol negotiation.

Perhaps your application is not sending a valid certificate or no
certificate at all or something like that, which then has nothing to do
with the inability to perform a full TLSv1.2 handshaking procedure. Is this
connection worked previously using a less secure protocol?


> Another interesting thing I found in my testing after the change to the
> SSL_VERSION was in place was when I connected to the web application using
> FTPS client using FileZilla in Debug mode to be able to see the connection
> logging, not only was the key presented to the client from the server using
> TLSv1.2 but the entire communication used TLSv1.2. Before the change only
> the key was presented to the client using TLSv1.2 and the rest of the
> communications showed TLSv1.0. So somehow the change to the SSL_VERSION
> parameter allowed this. I am of course the kid that turns around and asks
> "but why" :-)
>
>
Because previously you didn't complete the TLSv1.2 protocol handshaking
process given the fact you server didn't support it. It then negociated a
lesser protocol understood by both parties which happen to be TLSv1.0 (the
one set by the previous value of SSL_VERSION in your catalina.sh startup
file).

-
Daniel Savard

Re: Configuring Tomcat to support TLSv1.2

[Daniel Savard]

2016-06-24 11:15 GMT-04:00 Christopher Schultz :

>
> 
>
No SSL_VERSION environment variable is recognized by a stock Tomcat.
>

I see, however what I meant was the SSL_VERSION variable isn't defined in
the vanilla catalina.sh script. Jolene cleared out this in her next post
saying it was setup by the vendor. I was assuming she was working from a
vanilla installation someone else has customized somewhat, hence my
suggestion to stick on vanilla catalina.sh and so on.

---------
Daniel Savard

Re: Configuring Tomcat to support TLSv1.2

[Daniel Savard]

2016-06-21 19:08 GMT-04:00 Joleen Barker :

> Hello Daniel,
>
> Thank you for your replies.
>
> Yes, I have the Java build 1.7.0_71 installed and I have the Unlimited
> security package installed as the application from the vendor requires it.
>
> Ok, you say never to edit the catalina,sh. I can change it back. The
> settings originally was SSL_VERSION="-Dhttps.protocol=TLSv1"
>
>
I believe this is not from the original version of the file. I have no
longer any Tomcat 7 installed to check this, however if I am checking my
Tomcat 8 catalina.sh, there is no SSL_VERSION environment variable
anywhere. If you are having an already modified catalina.sh, it will be
difficult to provide any meaningful guidance.


> Why is it set for only one version in the catalina.sh what is having this
> set to one version limiting us to?
>
>
It seems your catalina.sh has already been modified by someone else. This
doesn't look like the vanilla version of the catalina.sh file.


> Our connector has this set in it:
>
> sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" sslProtocol="TLS"
>
> Is this all we need to allow TLSv1.2 clients to come in and for Tomcat
> acting as a client to go out as TLSv1.2?


You didn't provide enough details about your connector, so, read this page:
https://tomcat.apache.org/tomcat-7.0-doc/config/http.html

I assume you are configuring a NIO or BIO connector, then sslProtocol="TLS"
is the only needed attribute to support TLSv1, TLSv1.1 and TLSv1.2. The
sslEnabledProtocols attribute is not necessary since it overalps with
sslProtocol attribute. Note if you do not specify this attribute it
defaults to TLS anyway.

If you read the documentation page above, you will see the sslProtocol
attribute is actually passing the value to Java 7. That's why there is no
need to temper with the catalina.sh to try to set this for Java before
hand. The proper way to configure Tomcat is to modify files in the conf
directory only. Playing with files in bin and lib is not a recommended
approach.


Daniel Savard

Re: Configuring Tomcat to support TLSv1.2

[Daniel Savard]

2016-06-21 14:12 GMT-04:00 Joleen Barker :

> Hello Tomcat friends,
>
> I am looking for some understanding on what is happening in my environment
> to make sure I am not missing anything in my settings.
>
> Basics:
> 1) OS is GNU/Linux
> 2) Java is JDK v1.7
> 3) Tomcat 7
>
> First, this question has come up because we needed to allow TLSv1.2
> connections to our application. I was looking for how someone would do this
> and found 2 items. The first was to set the java https protocol to allow
> TLSv1.2 because by default java 7 did not have this enabled. The other was
> to set in Tomcat the SSL_VERSION parameter in catalina.sh. The site I read
> to set the SSL_VERSION in the catalina.sh indicated the user had to do this
> because his Tomcat would not talk to another Tomcat without this set. When
> I went in and looked the SSL_VERSION was set to TLSv1, so I added 1.1 and
> 1.2 with the following command:
>
> SSL_VERSION="-Dhttps.protocol=TLSv1,TLSv1.1,TLSv1.2"
>
> This change was easy to make but I learned a restart was needed for the
> change it take place.
>

Never ever edit catalina.sh, this is bad practice and strongly discouraged.
This file lies in the official binary distribution tree and should never
been tempered with. There is other ways to configure properly Tomcat. If
you change the connector properties, which is what you need to do to enable
TLSv1.2, there is not turnaround for a restart.


>
> Prior to me finding the change to make above I was reading to make the
> change for Java (not through Tomcat) I would run the command on the command
> line:
>
> java -Dhttps.protocol=TLSv1,TLSv1.1,TLSv1.2
>
> no matter how I ran this the command would not be taken.
>
>
Of course it would not affect another process than itself. This is totally
useless to execute this command alone.


> I did not think only making the change to the SSL_VERSION was enough but my
> colleague decided to try connecting to the Tomcat server with an SSH client
> and we received the notification that the TLSv1.2 connection was good.
>
> We finally were able to get a console working on the server and to our
> surprise Java's console did not have any of the TLS versions enabled and
> only the SSL versions.
>
> So I am confused here. It doesn't seem like Tomcat is relying on Java's
> settings matching what is in the catalina.sh file and works without setting
> these in the java console.
>
> Why is that?
>
> Thanks for improving my knowledge.
>
> -Joleen
>

You need to setup properly Tomcat othewise a setting somewhere may be
override elsewhere. For your connector to support TLSv1.2, you need to edit
the server.xml file and nothing else.

The other thing you will need to do, is to make the necessary steps for
your version of Java to support the TLSv1.2 if it doesn't support it yet.
You didn't mention which version of Java 7 exactly you are using. Did you
install the Unlimited JDK security package?

Did you read the documentation on TLS/SSL?
 http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html

-
Daniel Savard

Re: Updating Apache Tomcat to a current version

[Daniel Savard]

2016-06-12 19:32 GMT-04:00 paul.greene.va :

>
> A couple of quick questions - when you drop the WAR file into the webapps
> directory, does tomcat automatically expand the contents of the file? And
> is the WAR file format a typical way for vendors to distribute their apps
> to their customers, or is it normally a customer created file?
>
>
Hi Paul,

I assumed your previous configuration or the reference configuration is
doing so. Then, if you replicate the configuration it should do the same.

Regards,
---------
Daniel Savard

Re: Updating Apache Tomcat to a current version

[Daniel Savard]

2016-06-12 15:10 GMT-04:00 paul.greene.va :
>
> Daniel - sorry, this was probably confusing. What I did was install Tomcat
> 7.0.53 at *home* on a virtual server - there was nothing else installed on
> this virtual machine - no Service Manager, no apps, nothing else. I just
> wanted to see what happened when I went to install 7.0.69 over the top of
> .53; i.e. would there just be a simple "upgrade" option or not. There
> wasn't an option to "upgrade" and the install choked at one point when it
> realized there was another tomcat.exe process running and it couldn't
> overwrite the file.
>
> The server I need to upgrade at *work* is a perfectly functioning instance
> of Service Manager. It is working fine with no issues at the moment. I
> haven't touched anything on this server yet.
>
> It sounds like, from what you've said, the standard way to deploy an app
> in tomcat is via a WAR file getting dropped in the webapps directory. There
> is a sm.war file in the root of ..\webapps; if I copied that file into the
> new tomcat install webapps directory, would that install the app correctly?
> Or does a new *.war file need to be generated with a new version of tomcat?
> Service Manager itself isn't getting upgraded at this time, so if that was
> the same war file used in the last upgrade (they went from 9.33 to 9.40),
> shouldn't it work in this one too?
>
>
Paul,

you do not upgrade Tomcat code, you install a second instance of Tomcat or
you delete the existing Tomcat and install the new version.

Service Manager is pretty straight forward to install. Here are the setups:

1) Install Tomcat 7.0.69
2) Configure conf/server.xml (TLS/SSL stuff, Connector, etc)
3) Start Tomcat
4) Drop the war file in webapps
5) Edit webapps/sm/WEB-INF/web.xml to reflect your installation (SM server,
etc) after the war has been installed into its directory

You are done. Check in logs/catalina.out for error messages.

There is variants in the installation. This one seems to me the simplest on
given you are telling us the war file is actually in the webapps folder.

I am a bit surprised you were told to upgrade to Tomcat 7.0.69, which
version of SM are you running on the server? We still have SM running with
Java 6 and Tomcat 6.0.24 in production with SM 9.34. We are upgrading to SM
9.41, Tomcat 8 and Java 8. So far, SM is running smoothly in all our
environments. Usually HP support whatever version of Tomcat you have,
provided it meets the minimum requirements or unless a specific bug exists
in your Tomcat version.

Regards,
-
Daniel Savard

Re: Updating Apache Tomcat to a current version

[Daniel Savard]

2016-06-12 9:20 GMT-04:00 paul.greene.va :

>
> I got copies of both 7.0.53 and 7.0.69 off the Tomcat website, and
> installed .53 first on a vmware vm, then tried running .69 over it to see
> if it was just an easy upgrade, but it looks like Tomcat doesn't make the
> upgrade that easy.
>
>
It is unclear here if you have the HP application installed or not on
7.0.53 in you VM. If you don't, it is pointless to backup any content. The
idea of the backup is to keep a copy of the working configuration for
reference.


> So, if I understand your suggestions correctly, would the following plan
> of action work -
>
> Make a backup of everything under C:\Program Files\Apache Software
> Foundation\Tomcat 7.0\, in particular conf and webapps
> Remove the current version of Tomcat (.53)
> Install most recent version (.69)
> Copy the contents of the conf and webapps folder back to the new install
>
>
No, don't blindly copy contents. You can copy the WAR file in the webapps
folder. But you shouldn't just copy over the conf content. Usually, only
the server.xml is modified and you must look at the actual content and
adapt to your particular needs. The old copy being a reference provided it
is not just a vanilla copy.


> There is a *.keystore file and a keystore.jks files in the root of
> C:\Program Files\Apache Software Foundation\Tomcat 7.0\ - I'm guessing they
> are probably needed as well to get SSL working correctly (?)
>
>
If you have SSL enabled you should look into the server.xml for the files
you need to keep. You can relocate them provided you update the location in
the server.xml.


> Should that do the trick?
>
>
You must understand what you are doing. You cannot just blindly copy
everything and expect it to work. Usually, the Tomcat configuration is in
conf/server.xml and the web application configuration is in
webapps/whatever_name/WEB-INF/web.xml. However, with HP you may also have
other files in WEB-INF to edit to configure the application properly.


> (I'm not familiar with WAR files - is that the normal way to install new
> apps into Tomcat?)
>

WAR is the standard to distribute web applications.

Regards,
-
Daniel Savard

Re: Updating Apache Tomcat to a current version

[Daniel Savard]

2016-06-10 15:09 GMT-04:00 paul.greene.va :

> Actually, I don't want to have parallel versions going; 7.0.53 needs to go
> away to address the vulnerabilities found in the audit scan. Ideally
> everything should be the same as it is now, with the only difference being
> the app is using 7.0.69 rather than 7.0.53.


Hi Paul,

What I would do, is keep a copy of the files in conf directory/folder of
your old Tomcat instance as well as a copy of the files in webapps (I
suppose you have drop the war file into that directory/folder). You then
have a copy of all the files you need in case something went wrong or you
need to configure something you don't remember.

Then I would install the new Tomcat version. Configure the server.xml (I
suppose you did previously for the old version and know how to modify it to
reflect your particular needs) and then drop the war file in the new
wepapps directory if this is how you installed the old version of the HP
application. I suppose you have some kind of instructions from HP on how to
install their application. It is just like you install a brand new Tomcat.
The important part is to keep a copy of the old stuff in case you need to
refer to your previous settings.

Regards,
Daniel

Re: Updating Apache Tomcat to a current version

[Daniel Savard]

2016-06-09 23:04 GMT-04:00 paul.greene.va :

> Hello All,
>
> I manage an HP application that uses Apache Tomcat as a 3rd party
> application. The installed Tomcat version is 7.0.53. Because of a recent
> audit scan I have to update it to the most current version (7.0.69). HP
> says - "not our application; we don't support it".
>
> Is there an existing guide that describes how to update to a more recent
> version within the same series? (7, in this case). Maybe I'm just missing
> it but I cannot find anything that specific on the Apache Tomcat website.
>
> Tomcat is installed on 64 bit Windows 2012.
>
>
Hi Paul,

just look at the Tomcat documentation on how you can install multiple
versions of Tomcat in parallel on the same Windows server. You do not
upgrade Tomcat, you install the latest version and then you drop you HP
webapps in the new container, provided you have configured it properly. In
fact, you can run both versions of Tomcat in parallel with the HP webapps
if you wish. I am doing this at will and I am also running a bunch of HP
web applications. You can also configure Tomcat to use whatever version of
Java you wish and again, you can have multiple versions of Java if needed.

Regards,
Daniel

Clustering and Context Container setup

[Daniel Savard]

Hi everyone,

I am reviewing a clustering implementation I have done and after reading
the documentation for Tomcat 8, which is the version I am using (8.0.35 +
Oracle JDK1.8.0_92) I ran into the distributable attribute.

I saw in my configuration the distributable="true" attribute is set at the
Context container definition level rather than having a 
element in the web.xml of each web application in the cluster.

I cannot find this attribute documented in the Context container
documentation. Is it an omission or the attribute is deprecated or what?

I also saw in this documentation page:
http://tomcat.apache.org/tomcat-8.0-doc/config/cluster.html

The Context element should specify the
className="org.apache.catalina.ha.context.ReplicatedContext" in order to
enable the Context replication.

I am wondering if distributable="true" is equivalent to setting the
className to the value above or not? If not, what is the difference? I am
asking, because I did not set the className to this value and so far, it
seems to work.

What is the proper way with Tomcat 8 to setup the Context for clustering?

I also saw the sample configuration in the Clustering HOWTO documentation (
http://tomcat.apache.org/tomcat-8.0-doc/cluster-howto.html) and the
Interceptor MessageDispatch15Interceptor defined in this document is
deprecated and MessageDispatchInterceptor should be used instead. Which
make me doubt if this documentation is accurate or not. I found the
deprecated class while searching for the different values for
channelSendOptions.

Here:
http://tomcat.apache.org/tomcat-8.0-doc/api/org/apache/catalina/tribes/group/interceptors/MessageDispatch15Interceptor.html

So, a little clarification would be appreciated.

Regards,
-
Daniel Savard

Re: [SECURITY] Java Deserialization, JMX and CVE-2016-3427

[Daniel Savard]

2016-05-25 13:42 GMT-04:00 Mark Thomas :
(...)

> For example, this issue only applies if you are using JMX/RMI. If you
> are, it is likely to be a significant risk. If you aren't, it won't
> affect you. One of the reasons I published that blog post was to provide
> folks with the information they need to figure out whether this affects
> them or not.
>
> Mark
>

In doubt, I usually prefer to upgrade to latest version. I see no reason to
stick to a lower version unless a specific bug is know and has been
introduced into the latest version.

-
Daniel Savard

Re: Apache Tomcat 9

[Daniel Savard]

2016-05-06 14:27 GMT-04:00 Frederick Piña :

> Hi ! I'm using Tomcat Controller. It works fine (turning off/on, etc).
> However, after the confirmation page on my browser is shown; from Apache
> Tomcat 9; I still can't get the Java Web Application to load.
>
> Apache Tomcat 9 is working fine... But I'm also getting this error:
>
> *Caused by: java.net.BindException: Address already in use *
>
>
>
Address already in use means what it says. Either another Tomcat process is
already using the IP and port number specified in your server.xml file,
either another process not related to Tomcat is already using this IP and
port number.

It may happen if you start two instances of Tomcat with the same
configuration.

Re: performance of tomcat 8 is less than tomcat 6

[Daniel Savard]

2016-04-19 1:04 GMT-04:00 Ravi Chandra Suryavanshi <
ravi.chandra.suryavan...@ericsson.com>:

> Hi,
> I am using tomcat 6 in my product. I am planning to upgrade to tomcat 8 as
> tomcat is going to EoS in Dec-2016.
> I have just taken the performance of Tomcat 8 and found the 70% less
> performance compared to tomcat 6. See the below results Tomcat 6 is giving
> 167473.2/s whereas tomcat 8 is giving 100436.6/s
> I have just compared with two standalone tomcat which is just hitting the
> HelloWorld servlet available in example.
>
> Kindly let me know what need to configure to boost the performance.
>
> Following are my setup:
> Java=Java 8
> HttpClient=HttpClient4
> Benchmark tool=jmeter
>
> testserver:~# uname -a
> Linux testserver 3.10.0-229.el7.x86_64 #1 SMP Thu Jan 29 18:37:38 EST 2015
> x86_64 x86_64 x86_64 GNU/Linux
>
>
>
> testserver:~# lscpu
> Architecture:  x86_64
> CPU op-mode(s):32-bit, 64-bit
> Byte Order:Little Endian
> CPU(s):32
> On-line CPU(s) list:   0-31
> Thread(s) per core:2
> Core(s) per socket:8
> Socket(s): 2
> NUMA node(s):  2
> Vendor ID: GenuineIntel
> CPU family:6
> Model: 63
> Model name:Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
> Stepping:  2
> CPU MHz:   2600.000
> BogoMIPS:  5210.53
> Virtualization:VT-x
> L1d cache: 32K
> L1i cache: 32K
> L2 cache:  256K
> L3 cache:  20480K
> NUMA node0 CPU(s): 0-7,16-23
> NUMA node1 CPU(s): 8-15,24-31
>
> testserver:~# vmstat -s
> 131730840 K total memory
>   5931052 K used memory
>   7126352 K active memory
>   5511616 K inactive memory
> 116069376 K free memory
> 20888 K buffer memory
>   9709520 K swap cache
>  11681788 K total swap
> 0 K used swap
>  11681788 K free swap
>  54069797 non-nice user cpu ticks
>   997 nice user cpu ticks
>   9712353 system cpu ticks
>   15112937897 idle cpu ticks
> 37101 IO-wait cpu ticks
>73 IRQ cpu ticks
> 21245 softirq cpu ticks
> 0 stolen cpu ticks
>   8918100 pages paged in
> 267868897 pages paged out
> 0 pages swapped in
> 0 pages swapped out
>4281536287 interrupts
>4185543972 CPU context switches
>1456296771 boot time
>  84815522 forks
>
>
>
> Tomcat 6 performance
>
> Linux 3.10.0-229.el7.x86_64 (testserver) 04/19/2016  _x86_64_
>   (32 CPU)
> 05:36:33 PM CPU %user %nice   %system   %iowait%steal
>  %idle
> 05:36:38 PM all 37.66  0.00 14.69  0.10  0.00
>  47.55
> 05:36:43 PM all 37.61  0.00 14.50  0.01  0.00
>  47.89
> 05:36:48 PM all 38.31  0.00 14.48  0.03  0.00
>  47.19
> 05:36:53 PM all 37.45  0.00 14.53  0.01  0.00
>  48.01
> 05:36:58 PM all 37.97  0.00 14.67  0.02  0.00
>  47.34
> 05:37:03 PM all 37.68  0.00 14.62  0.01  0.00
>  47.69
>
> Created the tree successfully using HTTPRequest.jmx
> Starting the test @ Wed Apr 13 17:34:58 CEST 2016 (1460561698701)
> Waiting for possible shutdown message on port 4445
> summary +  16181 in   1.3s = 12893.2/s Avg: 0 Min: 0 Max:67
> Err: 0 (0.00%) Active: 3 Started: 3 Finished: 0
> summary + 5187350 in30s = 172911.7/s Avg: 0 Min: 0 Max:31
> Err: 0 (0.00%) Active: 24 Started: 24 Finished: 0
> summary = 5203531 in  31.3s = 166486.4/s Avg: 0 Min: 0 Max:67
> Err: 0 (0.00%)
> summary + 5207210 in30s = 173573.7/s Avg: 0 Min: 0 Max:26
> Err: 0 (0.00%) Active: 24 Started: 24 Finished: 0
> summary = 10410741 in  61.3s = 169957.4/s Avg: 0 Min: 0 Max:67
> Err: 0 (0.00%)
> summary + 5039715 in30s = 167990.5/s Avg: 0 Min: 0 Max:13
> Err: 0 (0.00%) Active: 24 Started: 24 Finished: 0
> summary = 15450456 in  91.3s = 169310.8/s Avg: 0 Min: 0 Max:67
> Err: 0 (0.00%)
> summary + 5024196 in30s = 167473.2/s Avg: 0 Min: 0 Max:22
> Err: 0 (0.00%) Active: 24 Started: 24 Finished: 0
> summary = 20474652 in   121s = 168856.1/s Avg: 0 Min: 0 Max:67
> Err: 0 (0.00%)
>
>
>
> --
> tomcat 8
>
> Linux 3.10.0-229.el7.x86_64 (testserver) 04/19/2016  _x86_64_
>   (32 CPU)
>
> 06:14:36 PM CPU %user %nice   %system   %iowait%steal
>  %idle
> 06:14:41 PM all 24.10  0.00  9.39  0.01  0.00
>  66.51
> 06:14:46 PM all 24.62  0.00  9.25  0.00  0.00
>  66.13
> 06:14:51 PM all 24.66  0.00  9.12  0.01  0.00
>  66.22
> 06:14:56 PM all 23.96  0.00   

Re: porting jsvc startup script from init.d to systemd tomcat.service, resolved

[Daniel Savard]

André,

I was just trying to understand why this was a so hard requirement to
run on port 80. The provided answers didn't help to understand why
this was hardly needed. I was just questioning and sometimes, we, yes
I include myself, look at a problem with a narrow view how to solve it
and it may be helpful to be provided alternate solutions.

But, anyway, enough on this.
-
Daniel Savard


2016-03-19 17:02 GMT-04:00 André Warnier (tomcat) :
> Daniel,
>
> first of all, stop top-posting (this applies to both of you). This is not
> the style of posting desired on this list.
> See http://tomcat.apache.org/lists.html#tomcat-users, #6.
>
> Secondly,
> the original poster (lyallex) wants to run Tomcat under Linux, without a
> front-end, as a webserver, listening on port 80, but running as a user which
> is not root.
> This is a legitimate way of running Tomcat, and it is not for you to tell
> him to run it otherwise.  Presumably, he knows what he is doing, under his
> circumstances.
>
> Tomcat by itself cannot do that, because it cannot by itself start as root,
> bind to port 80, and then switch users.
> The jsvc program (a "wrapper" for the JVM which runs Tomcat) allows this,
> which is why the OP wants to use it.
> But he has problems configuring this to run under systemd.
> And this was his question : how to run Tomcat as non-root under a JVM under
> jsvc under systemd, listening on port 80.
>
> I have not yet tried it myself, so I cannot really help.
> But I have a feeling that the information that you have provided earlier,
> can be extrapolated to the configuration which lyallex wants.
> So thank you for providing that information, and let's leave it at that.
> There is no need and no point in transforming this conversation into a flame
> now.
>
>
>
> On 19.03.2016 21:33, Daniel Savard wrote:
>>
>> I still don't see how the number of concurrent sessions is related to
>> the port number.
>>
>> The default ports for Tomcat are 8080 and 8443.
>>
>> For huge websites, usually you have a load balancer as a front-end
>> anyway. You then get the capability to distribute the workload on more
>> than one instance of Tomcat and/or servers, so, sticking on a single
>> port isn't desirable since many instances on a single server cannot
>> run on the same port. You get the capability to eliminate any
>> single-point of failure as well as getting the capability to implement
>> a non-stop environment making a Tomcat cluster.
>> -
>> Daniel Savard
>>
>>
>> 2016-03-19 15:40 GMT-04:00 Lyallex :
>>>
>>> 
>>>
>>> On 19 March 2016 at 19:19, Daniel Savard  wrote:
>>>>
>>>> I see what you were trying to achieve, however I don't see much
>>>> interest in that.
>>>
>>>
>>> Really, I've been running a successful commercial web site for the
>>> last 4 years using Tomcat as a standalone web server
>>> and servlet container using exactly this solution. 1000 concurrent
>>> sessions pose no problem
>>> I mentioned this in my first post, sorry if you missed it.
>>>
>>>> 1) Obviously, if you were expecting systemd to solve that problem, you
>>>> were wrong and it is a sane behavir of systemd to not allow that
>>>> neither
>>>
>>>
>>> No, you misunderstood. I was trying to start jsvc from a systemd service
>>> file
>>> Please read more carefully.I never suggested that systemd would solve
>>> the problem
>>>
>>>> 2) Your solution to your problem is lying on jsvc alone.
>>>> 3) I believe is bad security practice to insist to bind on privileged
>>>> ports for process that don't need that level of privilege.
>>>>
>>>> Btw, even if you switch to another user to run the code, you actually
>>>> are binding to port 80 as root.
>>>>
>>>> Maybe you can explain us why you want to do such a thing and using any
>>>> other unprivileged port isn't a solution to your problem.
>>>
>>>
>>> What is the default port for non.-encrypted http traffic to a web server?
>>>
>>> Anyway, I see no reason to start a slanging match, I have better things
>>> to do.
>>> It's all working quite nicely now anyway, thank you for your input.
>>>
>>> To learn about jsvc see
>>> http://commons.apache.org/proper/commons-daemon/jsvc.html
>>> You'll need an up to date ANSI C compiler (I use gcc)
>>>
>>> Lyallex
>>>
>>

Re: porting jsvc startup script from init.d to systemd tomcat.service, resolved

[Daniel Savard]

I still don't see how the number of concurrent sessions is related to
the port number.

The default ports for Tomcat are 8080 and 8443.

For huge websites, usually you have a load balancer as a front-end
anyway. You then get the capability to distribute the workload on more
than one instance of Tomcat and/or servers, so, sticking on a single
port isn't desirable since many instances on a single server cannot
run on the same port. You get the capability to eliminate any
single-point of failure as well as getting the capability to implement
a non-stop environment making a Tomcat cluster.
-----
Daniel Savard


2016-03-19 15:40 GMT-04:00 Lyallex :
> 
>
> On 19 March 2016 at 19:19, Daniel Savard  wrote:
>> I see what you were trying to achieve, however I don't see much
>> interest in that.
>
> Really, I've been running a successful commercial web site for the
> last 4 years using Tomcat as a standalone web server
> and servlet container using exactly this solution. 1000 concurrent
> sessions pose no problem
> I mentioned this in my first post, sorry if you missed it.
>
>> 1) Obviously, if you were expecting systemd to solve that problem, you
>> were wrong and it is a sane behavir of systemd to not allow that
>> neither
>
> No, you misunderstood. I was trying to start jsvc from a systemd service file
> Please read more carefully.I never suggested that systemd would solve
> the problem
>
>> 2) Your solution to your problem is lying on jsvc alone.
>> 3) I believe is bad security practice to insist to bind on privileged
>> ports for process that don't need that level of privilege.
>>
>> Btw, even if you switch to another user to run the code, you actually
>> are binding to port 80 as root.
>>
>> Maybe you can explain us why you want to do such a thing and using any
>> other unprivileged port isn't a solution to your problem.
>
> What is the default port for non.-encrypted http traffic to a web server?
>
> Anyway, I see no reason to start a slanging match, I have better things to do.
> It's all working quite nicely now anyway, thank you for your input.
>
> To learn about jsvc see
> http://commons.apache.org/proper/commons-daemon/jsvc.html
> You'll need an up to date ANSI C compiler (I use gcc)
>
> Lyallex
>
>
>>
>> Regards,
>> -
>> Daniel Savard
>>
>>
>> 2016-03-19 12:10 GMT-04:00 Lyallex :
>>> It's the simplest way to find out which port you have Tomcat listening on
>>>
>>> *NIX based systems don't allow non root uses bind to ports < 1024
>>>
>>> jsvc
>>> http://commons.apache.org/proper/commons-daemon/jsvc.html
>>>
>>> solves this problem, nobody seems to have grasped that this is what I
>>> was asking about.
>>> I know of no way to start the container, on port 80 using either
>>> startup.sh or catalina.sh using start, run or anything else.
>>> If I'm wrong then I would love to see how it's done.
>>>
>>> CentOS Linux release 7.2.1511 (Core)
>>>
>>>
>>> On 19 March 2016 at 13:46, Daniel Savard  wrote:
>>>> Why? What is the point? The server.xml has nothing to do with
>>>> integration with systemd.
>>>> -
>>>> Daniel Savard
>>>>
>>>>
>>>> 2016-03-19 1:40 GMT-04:00 Lyallex :
>>>>> Would you mind posting your server.xml, here is the relevant bit from 
>>>>> mine.
>>>>>
>>>>>  
>>>>>
>>>>> >>>>connectionTimeout="2"
>>>>>redirectPort="8443" />
>>>>>
>>>>> 
>>>>>
>>>>>   
>>>>>
>>>>> >>>> resourceName="UserDatabase"/>
>>>>>
>>>>>   
>>>>>
>>>>>   >>>> autoDeploy="true">
>>>>>
>>>>> >>>> directory="logs"
>>>>>prefix="localhost_access_log" suffix=".txt"
>>>>>rotatable="false" pattern="combined" />
>>>>>   
>>>>>
>>>>> 
>>>>>   
>>>>>
>>>>> On 18 March 2016 at 23:35, Daniel Savard  wrote:
>>>>>> I believe all distros have over engineered the scripts to start
>>>>>> Tomcat. Forget all the

Re: porting jsvc startup script from init.d to systemd tomcat.service, resolved

[Daniel Savard]

I see what you were trying to achieve, however I don't see much
interest in that.

1) Obviously, if you were expecting systemd to solve that problem, you
were wrong and it is a sane behavior of systemd to not allow that
neither.
2) Your solution to your problem is lying on jsvc alone.
3) I believe is bad security practice to insist to bind on privileged
ports for process that don't need that level of privilege.

Btw, even if you switch to another user to run the code, you actually
are binding to port 80 as root.

Maybe you can explain us why you want to do such a thing and using any
other unprivileged port isn't a solution to your problem.

Regards,
---------
Daniel Savard


2016-03-19 12:10 GMT-04:00 Lyallex :
> It's the simplest way to find out which port you have Tomcat listening on
>
> *NIX based systems don't allow non root uses bind to ports < 1024
>
> jsvc
> http://commons.apache.org/proper/commons-daemon/jsvc.html
>
> solves this problem, nobody seems to have grasped that this is what I
> was asking about.
> I know of no way to start the container, on port 80 using either
> startup.sh or catalina.sh using start, run or anything else.
> If I'm wrong then I would love to see how it's done.
>
> CentOS Linux release 7.2.1511 (Core)
>
>
> On 19 March 2016 at 13:46, Daniel Savard  wrote:
>> Why? What is the point? The server.xml has nothing to do with
>> integration with systemd.
>> -
>> Daniel Savard
>>
>>
>> 2016-03-19 1:40 GMT-04:00 Lyallex :
>>> Would you mind posting your server.xml, here is the relevant bit from mine.
>>>
>>>  
>>>
>>> >>connectionTimeout="2"
>>>redirectPort="8443" />
>>>
>>> 
>>>
>>>   
>>>
>>> >> resourceName="UserDatabase"/>
>>>
>>>   
>>>
>>>   >> autoDeploy="true">
>>>
>>> >> directory="logs"
>>>prefix="localhost_access_log" suffix=".txt"
>>>rotatable="false" pattern="combined" />
>>>   
>>>
>>> 
>>>   
>>>
>>> On 18 March 2016 at 23:35, Daniel Savard  wrote:
>>>> I believe all distros have over engineered the scripts to start
>>>> Tomcat. Forget all the scripts from your distro, learn the
>>>> signification of the environment variables from the catalina.sh script
>>>> shipped with the default Tomcat version. Define your variables in a
>>>> file, this file is not a script, so you cannot reuse a previously
>>>> defined variable, feed your systemd service definition file with this
>>>> file in the service section as EnvironmentFile=/path/name/to/your/file
>>>> ExecStart=/path/to/catalina.sh start
>>>> ExecStop=/path/to/catalina.sh stop
>>>>
>>>> and you are done. You control everything from the environment file,
>>>> you can easily manage the environment variables without editing the
>>>> systemd's service file.
>>>>
>>>> It is much simpler than the OpenRC set of scripts at my humble
>>>> opinion. I am running Gentoo at home and RHEL at work and both distros
>>>> wrapped Tomcat into too many layers of scripts in order to make it
>>>> working with OpenRC while none of these are required to run and manage
>>>> Tomcat with systemd.
>>>>
>>>> In particular with Gentoo, I no longer use the Tomcat distro packaged
>>>> with Gentoo because they separated the servlet api from Tomcat and you
>>>> need to wrap things into layers of scripts to define the classpath
>>>> properly taking this into account, the vanilla classpath.sh file
>>>> distributed with Tomcat doesn't work and so one. Really, they did a
>>>> very bad job at integrating Tomcat.
>>>>
>>>> Here is my service file:
>>>>
>>>> [Unit]
>>>> Description=Tomcat 8 (Dev)
>>>> After=syslog.target
>>>> After=network.target
>>>>
>>>> [Service]
>>>> EnvironmentFile=/tomcat/tomcat-8-dev/bin/tomcat-8-dev.env
>>>> Type=forking
>>>> User=tomcat
>>>> Group=tomcat
>>>> ExecStart=/opt/apache-tomcat/apache-tomcat-8.0.32_ds/bin/catalina.sh start
>>>> ExecStop=/opt/apache-tomcat/apache-tomcat-8.0.32_ds/bin/catalina.sh stop
>>>&

Re: porting jsvc startup script from init.d to systemd tomcat.service, resolved

[Daniel Savard]

Why? What is the point? The server.xml has nothing to do with
integration with systemd.
-
Daniel Savard


2016-03-19 1:40 GMT-04:00 Lyallex :
> Would you mind posting your server.xml, here is the relevant bit from mine.
>
>  
>
> connectionTimeout="2"
>redirectPort="8443" />
>
> 
>
>   
>
>  resourceName="UserDatabase"/>
>
>   
>
>autoDeploy="true">
>
>  directory="logs"
>prefix="localhost_access_log" suffix=".txt"
>rotatable="false" pattern="combined" />
>   
>
> 
>   
>
> On 18 March 2016 at 23:35, Daniel Savard  wrote:
>> I believe all distros have over engineered the scripts to start
>> Tomcat. Forget all the scripts from your distro, learn the
>> signification of the environment variables from the catalina.sh script
>> shipped with the default Tomcat version. Define your variables in a
>> file, this file is not a script, so you cannot reuse a previously
>> defined variable, feed your systemd service definition file with this
>> file in the service section as EnvironmentFile=/path/name/to/your/file
>> ExecStart=/path/to/catalina.sh start
>> ExecStop=/path/to/catalina.sh stop
>>
>> and you are done. You control everything from the environment file,
>> you can easily manage the environment variables without editing the
>> systemd's service file.
>>
>> It is much simpler than the OpenRC set of scripts at my humble
>> opinion. I am running Gentoo at home and RHEL at work and both distros
>> wrapped Tomcat into too many layers of scripts in order to make it
>> working with OpenRC while none of these are required to run and manage
>> Tomcat with systemd.
>>
>> In particular with Gentoo, I no longer use the Tomcat distro packaged
>> with Gentoo because they separated the servlet api from Tomcat and you
>> need to wrap things into layers of scripts to define the classpath
>> properly taking this into account, the vanilla classpath.sh file
>> distributed with Tomcat doesn't work and so one. Really, they did a
>> very bad job at integrating Tomcat.
>>
>> Here is my service file:
>>
>> [Unit]
>> Description=Tomcat 8 (Dev)
>> After=syslog.target
>> After=network.target
>>
>> [Service]
>> EnvironmentFile=/tomcat/tomcat-8-dev/bin/tomcat-8-dev.env
>> Type=forking
>> User=tomcat
>> Group=tomcat
>> ExecStart=/opt/apache-tomcat/apache-tomcat-8.0.32_ds/bin/catalina.sh start
>> ExecStop=/opt/apache-tomcat/apache-tomcat-8.0.32_ds/bin/catalina.sh stop
>>
>> [Install]
>> WantedBy=multi-user.target
>>
>>
>> And here is the content of my EnvironmentFile:
>>
>> CATALINA_HOME="/opt/apache-tomcat/apache-tomcat-8.0.32_ds"
>> CATALINA_BASE="/tomcat/tomcat-8-dev"
>> CATALINA_OUT="/var/log/tomcat-8-dev/catalina.out"
>> JAVA_HOME="/opt/oracle-jdk-bin-1.8.0.74"
>> CATALINA_PID="/var/run/tomcat-8-dev.pid"
>>
>>
>> -
>> Daniel Savard
>>
>>
>> 2016-03-18 13:31 GMT-04:00 Lyallex :
>>> I thought you might be interested in the resolution to this.
>>>
>>> It turns out that we needed to reproduce the environment in tomcat.service
>>>
>>> For some reason
>>>
>>> ExecStart=/etc/rc.d/init.d/tomcat7 doesn't work
>>> (file shown at the end of this message)
>>>
>>> Instead, in  /etc/systemd/system/tomcat.service
>>> we have had to reproduce the environment in longhand to get it to work.
>>> It appears that systemd doesn't expand variables so I really need to
>>> investigate the systemd Environment thing a bit more.
>>> Anyway, when I shutdown -r now the server comes back up and tomcat is
>>> running at the unprivileged tomcat user on port 80 so that's a result
>>>
>>> == /etc/systemd/system/tomcat.service 
>>> [Unit]
>>> Description=Apache Tomcat Web Application Container
>>> After=network.target
>>>
>>> [Service]
>>> Type=forking
>>> User=root
>>>
>>> ExecStart=/opt/apache-tomcat-7.0.42/bin/jsvc \
>>> -user tomcat \
>>> -home /opt/jdk1.7.0_45 \
>>> -Dcatalina.home=/opt/apache-tomcat-7.0.42 \
>>> -Dcatalina.base=/opt/apache-tomcat-7.0.42 \
>>> -Djava.io.tmpdir=/var/tmp \
>>> -

Re: contextDestroyed() method not called

[Daniel Savard]

Hi Chuck,

I'm running it on Window 2012 Server as well as Linux RHEL.

And no, I am not sending a terminate signal with kill -9. That's why I
said I am stopping the application or the instance (both cases depict
the same behavior) rather than saying I am terminating it.

Regards,
-----
Daniel Savard


2016-03-16 23:56 GMT-04:00 Caldarale, Charles R :
>> From: Daniel Savard [mailto:daniel.sav...@gmail.com]
>> Subject: contextDestroyed() method not called
>
>> I noticed a problem with one of my web applications which requires
>> some cleanup when shutdown. It seems this cleanup isn't happening even
>> if everything has been put in the contextDestroyed() method of my web
>> listener.
>
>> I find it difficult to believe this is a bug in Tomcat, so, I guess I
>> am doing something wrong. Someone can provide some guidance to
>> identify the cause of such undesirable behavior?
>
> Missing a couple useful bits of information:
>
> 1) What OS are you running on?
>
> 2) More importantly, how are you shutting down Tomcat?  (Using kill -9 would 
> not be a good choice...)
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
> MATERIAL and is thus for use only by the intended recipient. If you received 
> this in error, please contact the sender and delete the e-mail and its 
> attachments from all computers.
>
>
> -
> 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: contextDestroyed() method not called

[Daniel Savard]

>From the manager clicking on the Stop button for the application. For
the instance, on Windows just stop the Tomcat service, on Linux, just
run the catalina.sh stop script.
-----
Daniel Savard


2016-03-17 8:47 GMT-04:00 Caldarale, Charles R :
>> From: Daniel Savard [mailto:daniel.sav...@gmail.com]
>> Subject: Re: contextDestroyed() method not called
>
> Read the mailing list rules: don't top post.
> http://tomcat.apache.org/lists.html#tomcat-users
>
>> I'm running it on Window 2012 Server as well as Linux RHEL.
>
> Ok, good to know.
>
>> And no, I am not sending a terminate signal with kill -9. That's why I
>> said I am stopping the application or the instance (both cases depict
>> the same behavior) rather than saying I am terminating it.
>
> Again, how are you doing this?
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
> MATERIAL and is thus for use only by the intended recipient. If you received 
> this in error, please contact the sender and delete the e-mail and its 
> attachments from all computers.
>
>
> -
> 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

contextDestroyed() method not called

[Daniel Savard]

Hi everyone,

I noticed a problem with one of my web applications which requires
some cleanup when shutdown. It seems this cleanup isn't happening even
if everything has been put in the contextDestroyed() method of my web
listener. So, to debug this problem I wrote a minimal web listener and
tested to see what is going on. It seems the contextDestroyed() method
isn't called when stopping the web application or stopping the Tomcat
instance.

Here is my minimal code:

package some.thing;

import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
import javax.servlet.annotation.WebListener;

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

@WebListener
public class TestContext implements ServletContextListener {

private Logger log = LogManager.getLogger();

public TestContext() {
 log.info("Constructor");
}

@Override
public void contextDestroyed(ServletContextEvent arg0) {
  log.info("Context destroyed.");
}

@Override
public void contextInitialized(ServletContextEvent arg0) {
  log.info("Context initialized.");
}

}

The constructor's info and the contextInitialized() info are both
written to my log file, the info from the contextDestroyed() method is
missing.

I am running Tomcat 8.0.32 with Java 1.8.0.74, but I have seen a
similar behavior with Tomcat 6.0.24 and Java 1.6.0.91 as well. I am
using log4j 2.5.

I find it difficult to believe this is a bug in Tomcat, so, I guess I
am doing something wrong. Someone can provide some guidance to
identify the cause of such undesirable behavior?

Regards,
-
Daniel Savard

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: porting jsvc startup script from init.d to systemd tomcat.service, resolved

[Daniel Savard]

I believe all distros have over engineered the scripts to start
Tomcat. Forget all the scripts from your distro, learn the
signification of the environment variables from the catalina.sh script
shipped with the default Tomcat version. Define your variables in a
file, this file is not a script, so you cannot reuse a previously
defined variable, feed your systemd service definition file with this
file in the service section as EnvironmentFile=/path/name/to/your/file
ExecStart=/path/to/catalina.sh start
ExecStop=/path/to/catalina.sh stop

and you are done. You control everything from the environment file,
you can easily manage the environment variables without editing the
systemd's service file.

It is much simpler than the OpenRC set of scripts at my humble
opinion. I am running Gentoo at home and RHEL at work and both distros
wrapped Tomcat into too many layers of scripts in order to make it
working with OpenRC while none of these are required to run and manage
Tomcat with systemd.

In particular with Gentoo, I no longer use the Tomcat distro packaged
with Gentoo because they separated the servlet api from Tomcat and you
need to wrap things into layers of scripts to define the classpath
properly taking this into account, the vanilla classpath.sh file
distributed with Tomcat doesn't work and so one. Really, they did a
very bad job at integrating Tomcat.

Here is my service file:

[Unit]
Description=Tomcat 8 (Dev)
After=syslog.target
After=network.target

[Service]
EnvironmentFile=/tomcat/tomcat-8-dev/bin/tomcat-8-dev.env
Type=forking
User=tomcat
Group=tomcat
ExecStart=/opt/apache-tomcat/apache-tomcat-8.0.32_ds/bin/catalina.sh start
ExecStop=/opt/apache-tomcat/apache-tomcat-8.0.32_ds/bin/catalina.sh stop

[Install]
WantedBy=multi-user.target


And here is the content of my EnvironmentFile:

CATALINA_HOME="/opt/apache-tomcat/apache-tomcat-8.0.32_ds"
CATALINA_BASE="/tomcat/tomcat-8-dev"
CATALINA_OUT="/var/log/tomcat-8-dev/catalina.out"
JAVA_HOME="/opt/oracle-jdk-bin-1.8.0.74"
CATALINA_PID="/var/run/tomcat-8-dev.pid"


-
Daniel Savard


2016-03-18 13:31 GMT-04:00 Lyallex :
> I thought you might be interested in the resolution to this.
>
> It turns out that we needed to reproduce the environment in tomcat.service
>
> For some reason
>
> ExecStart=/etc/rc.d/init.d/tomcat7 doesn't work
> (file shown at the end of this message)
>
> Instead, in  /etc/systemd/system/tomcat.service
> we have had to reproduce the environment in longhand to get it to work.
> It appears that systemd doesn't expand variables so I really need to
> investigate the systemd Environment thing a bit more.
> Anyway, when I shutdown -r now the server comes back up and tomcat is
> running at the unprivileged tomcat user on port 80 so that's a result
>
> == /etc/systemd/system/tomcat.service 
> [Unit]
> Description=Apache Tomcat Web Application Container
> After=network.target
>
> [Service]
> Type=forking
> User=root
>
> ExecStart=/opt/apache-tomcat-7.0.42/bin/jsvc \
> -user tomcat \
> -home /opt/jdk1.7.0_45 \
> -Dcatalina.home=/opt/apache-tomcat-7.0.42 \
> -Dcatalina.base=/opt/apache-tomcat-7.0.42 \
> -Djava.io.tmpdir=/var/tmp \
> -Djava.awt.headless=true \
> -Xms512m \
> -Xmx1024m \
> -outfile /opt/apache-tomcat-7.0.42/logs/catalina.out \
> -errfile /opt/apache-tomcat-7.0.42/logs/catalina.err \
> -pidfile /var/run/tc7/jsvc.pid \
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \
> -Djava.util.logging.config.file=/opt/apache-tomcat-7.0.42/conf/logging.properties
> \
> -cp 
> /opt/apache-tomcat-7.0.42/bin/bootstrap.jar:/opt/apache-tomcat-7.0.42/bin/commons-daemon.jar:/opt/jdk1.7.0_45/lib/tools.jar:/opt/apache-tomcat-7.0.42/bin/tomcat-juli.jar
> \
> org.apache.catalina.startup.Bootstrap
>
> ExecStop=/bin/kill -9 /var/run/tc7/jsvc.pid
> ExecStopPost=/bin/rm -f /var/tc7lock/subsys/tomcat /var/run/tc7/jsvc.pid
>
> [Install]
> WantedBy=multi-user.target
>
>
> Oh happy day
> Thanks again to all responders
>
> Lyallex
>
> = /etc/rc.d/init.d/tomcat7  =
>
> JAVA_HOME=/opt/jdk1.7.0_45
> CATALINA_HOME=/opt/apache-tomcat-7.0.42
> export JAVA_HOME CATALINA_HOME
> CLASSPATH=$CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/commons-daemon.jar:$JAVA_HOME/lib/tools.jar:$CATALINA_HOME/bin/tomcat-juli.jar
> TOMCAT_USER=tomcat
> TMPDIR=/var/tmp
> PIDFILE=/var/run/tc7/jsvc.pid
>
>
> RC=0
>
> case "$1" in
>
>   start)
>
>$CATALINA_HOME/bin/jsvc -user $TOMCAT_USER -home $JAVA_HOME
> -Dcatalina.home=/opt/apache-tomcat-7.0.42
> -Dcatalina.base=$CATALINA_HOME -Djava.io.tmpdir=$TMPDIR
> -Djava.awt.headless=true \
>  -Xms512m \
>  -Xmx102

Re: contextDestroyed() method not called

[Daniel Savard]

Nevermind, the contextDestroyed() method is actually called as
supposed and expected. The problem seems the logger is no longer able
to output anything in the log file at this point even if I configured
it to flush immediately the output. I replaced the log.info()
statement by a System.out.println() followed by a System.out.flush()
and I can see the output.

However, it seems the context is destroyed before my objects are
themselves destroyed since I still receive messages in the
catalina.out about them, like this one:

INFOS: Closing Spring root WebApplicationContext
Destruction du contexte applicatif. Application: CaissesDispo,
Serveur: Apache Tomcat/8.0.32_ds
Désinscrit les écouteurs de requêtes uCMDB.
Détruit le bassin de connexions uCMDB.
Application: CaissesDispo terminée.
mars 17, 2016 7:44:15 PM
org.apache.catalina.loader.WebappClassLoaderBase
clearReferencesThreads
AVERTISSEMENT: The web application [CaissesDispo] appears to have
started a thread named [UCMDB Model Notifications Service Notification
Thread] but has failed to stop it. This is very likely to create a
memory leak. Stack trace of thread:
 sun.misc.Unsafe.park(Native Method)
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
 
com.hp.ucmdb.api.client.topology.notification.AbstractNotificationService$NotifyListeners.run(AbstractNotificationService.java:244)
 java.lang.Thread.run(Thread.java:745)
mars 17, 2016 7:44:15 PM
org.apache.catalina.loader.WebappClassLoaderBase
clearReferencesThreads


Anything can be done to avoid these messages if the objects are
actually destroyed?

-
Daniel Savard


2016-03-17 19:08 GMT-04:00 Daniel Savard :
> From the manager clicking on the Stop button for the application. For
> the instance, on Windows just stop the Tomcat service, on Linux, just
> run the catalina.sh stop script.
> -----
> Daniel Savard
>
>
> 2016-03-17 8:47 GMT-04:00 Caldarale, Charles R :
>>> From: Daniel Savard [mailto:daniel.sav...@gmail.com]
>>> Subject: Re: contextDestroyed() method not called
>>
>> Read the mailing list rules: don't top post.
>> http://tomcat.apache.org/lists.html#tomcat-users
>>
>>> I'm running it on Window 2012 Server as well as Linux RHEL.
>>
>> Ok, good to know.
>>
>>> And no, I am not sending a terminate signal with kill -9. That's why I
>>> said I am stopping the application or the instance (both cases depict
>>> the same behavior) rather than saying I am terminating it.
>>
>> Again, how are you doing this?
>>
>>  - Chuck
>>
>>
>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
>> MATERIAL and is thus for use only by the intended recipient. If you received 
>> this in error, please contact the sender and delete the e-mail and its 
>> attachments from all computers.
>>
>>
>> -
>> 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: Connection pool in a clustered environment

[Daniel Savard]

Hi Chris,

thanks for the explanations. I just completed a first dirty test and
it is actually working fine. I believe I did something wrong on my
first trial. I did put the distributable="true" attribute in the
Context element of my context file in
$CATALINA_BASE/conf/[[enginename]/[hostname]/mywebapp.xml instead of
adding the empty element  in
$CATALINA_BASE/webapps/mywebapp/WEB-INF/web.xml.

It seems the former is not working, at least with Tomcat 8.0.32
-----
Daniel Savard


2016-03-08 15:08 GMT-05:00 Christopher Schultz :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Daniel,
>
> On 3/8/16 2:27 PM, Daniel Savard wrote:
>> I wonder how you handle a pool of connections (not necessarily to
>> a database, think about something generic) in a clustered
>> environement.
>
> Generally, there is nothing to be done, here. Each node is considered
> completely separate with the exception of trading HttpSession informatio
> n.
>
>> I defined a pool of connections in my application context and I
>> did put it in the context with the setAttribute() method. Since
>> each instance is doing this, what will happen when an instance is
>> shutdown?
>
> I believe that no context-scoped data is sent between cluster nodes,
> so ... nothing will happen.
>
>> These connections depend on the IP/protocol/port on both sides.
>> So, since the instance is down, one party no longer exists. What
>> is happening if a take over instance receives an incoming request
>> which refers to one of these connections?
>>
>> Do I have to handle this in my code? Do I have to reinitialize the
>> connection pool if such an event happen?
>
> If your application maintains its own connection pool, then you should
> create it with each webapp start and destroy it with each webapp stop.
>
> I don't think there are any cluster-related issues, here.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlbfMTIACgkQ9CaO5/Lv0PCL5gCguI2eODlB+8Brz9gpjJZGGzpM
> jD4An1Nag5xcNN+2vXKq7xpw6H8Gdhg/
> =Gx0w
> -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

Connection pool in a clustered environment

[Daniel Savard]

Hi everyone,

I wonder how you handle a pool of connections (not necessarily to a
database, think about something generic) in a clustered environement.

I defined a pool of connections in my application context and I did
put it in the context with the setAttribute() method. Since each
instance is doing this, what will happen when an instance is shutdown?
These connections depend on the IP/protocol/port on both sides. So,
since the instance is down, one party no longer exists. What is
happening if a take over instance receives an incoming request which
refers to one of these connections?

Do I have to handle this in my code? Do I have to reinitialize the
connection pool if such an event happen?

Regards,
-
Daniel Savard

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Advice on Cluster in one machine

[Daniel Savard]

On the zero downtime deployments side, I would prefer a parallel
deployment approach. You can deploy a new version within the same
instance and have zero downtime as well without building a cluster.

I haven't experiment yet with this, but it is something I am looking
forward to test in short term.
-
Daniel Savard


2016-03-08 10:48 GMT-05:00 Christopher Schultz :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Edwin,
>
> On 3/8/16 8:19 AM, Edwin Quijada wrote:
>> I am new using Tomcat so I have a question about performance. I
>> have installed a cluster with 2 tomcats and apache webserver like
>> proxy in front of Tomcat cluster but this whole thing is in one
>> server, somebody tell me that is not useful beacuse is in the same
>> server that is better give more resources to one tomcat and not
>> split the resources in two.
>
> Performance-wise, your friend is right: a two-node cluster on one
> machine is going to use more resources than a single node on that machin
> e.
>
> However, running two cluster nodes on a single server isn't a
> completely stupid idea. If you want to have zero-downtime deployments,
> you can take one node down, upgrade it, then switch. So there's value
> there. As for fault-tolerance, the single point of failure is the
> whole machine: if that server isn't available, no services are available
> .
>
> That's why people usually have a hardware load balancer (fairly
> simple, fairly reliable) and several web/app servers, just in case one
> of them fails. If one node fails, the service is still available.
>
>> Somebody here can give any advice about this configuration what do
>> you think about this ? In this server I have websockets in cluster
>> and I am having problems with websockets in cluster
>
> Clustering and websockets have little to do with one another, since
> the connection goes to one node and the cluster really just manages
> things like sessions (which are orthogonal to connections, protocols,
> etc.).
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlbe9DcACgkQ9CaO5/Lv0PCvSACeP5LxHVddVmygYBSDCMy/bzyI
> kcsAoMRRZOREaWubUGJFrviRSx/cVAUK
> =1OIe
> -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: Configuring a custom folder for Tomcat configuration files

[Daniel Savard]

Your question has been answered and you shouldn't cross post questions.
-
Daniel Savard


2016-03-08 3:31 GMT-05:00 Chiranga Alwis :
> Hi,
>
> please refer the question in stackoverflow
> http://stackoverflow.com/questions/35862427/configuring-custom-tomcat-configuration-folder
> .
>
> Is this possible? Any help is highly appreciated.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Building binary release on Windows 10

[Daniel Savard]

Thanks Konstantin, I should have noticed the section in the
BUILDING.txt, I read it once and didn't need the installer at that
time, so I just forgot about it.

Yes, I need the installer to distribute and installer version to
someone else for a patch I made to the code and who couldn't cope with
anything else, unfortunately.
-----
Daniel Savard


2016-02-14 7:06 GMT-05:00 Konstantin Kolinko :
> 2016-02-14 4:50 GMT+03:00 Daniel Savard :
>> Hi everyone,
>>
>> I am trying to perform a "build release" from source code for Tomcat
>> 8.0.32 and I am running into the following error when it is time to
>> create the actual installer file.
>>
>>
>> BUILD FAILED
>> E:\Utilisateurs\dsavard\Projets\apache-tomcat-8.0.32-src\build.xml:2223:
>> Execute failed: java.io.IOException: Cannot run program
>> "E:\Utilisateurs\dsavard\Projets\apache-tomcat-8.0.32-src\output\dist\tempinstaller.exe"
>> (in directory 
>> "E:\Utilisateurs\dsavard\Projets\apache-tomcat-8.0.32-src\output\dist"):
>> CreateProcess error=740, L'opération demandée nécessite une élévation
>> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1047)
>> at java.lang.Runtime.exec(Runtime.java:617)
>> at 
>> org.apache.tools.ant.taskdefs.launcher.Java13CommandLauncher.exec(Java13CommandLauncher.java:58)
>> at org.apache.tools.ant.taskdefs.Execute.launch(Execute.java:428)
>> at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:442)
>> at 
>> org.apache.tools.ant.taskdefs.ExecTask.runExecute(ExecTask.java:629)
>> at org.apache.tools.ant.taskdefs.ExecTask.runExec(ExecTask.java:670)
>> at org.apache.tools.ant.taskdefs.ExecTask.execute(ExecTask.java:496)
>> at 
>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293)
>> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
>> at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:606)
>> at 
>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
>> at org.apache.tools.ant.Task.perform(Task.java:348)
>> at org.apache.tools.ant.Target.execute(Target.java:435)
>> at org.apache.tools.ant.Target.performTasks(Target.java:456)
>> at 
>> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1405)
>> at org.apache.tools.ant.Project.executeTarget(Project.java:1376)
>> at 
>> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
>> at org.apache.tools.ant.Project.executeTargets(Project.java:1260)
>> at org.apache.tools.ant.Main.runBuild(Main.java:853)
>> at org.apache.tools.ant.Main.startAnt(Main.java:235)
>> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:285)
>> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:112)
>> Caused by: java.io.IOException: CreateProcess error=740, L'opération
>> demandée nécessite une élévation
>> at java.lang.ProcessImpl.create(Native Method)
>> at java.lang.ProcessImpl.(ProcessImpl.java:385)
>> at java.lang.ProcessImpl.start(ProcessImpl.java:136)
>> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1028)
>> ... 23 more
>>
>> Total time: 1 minute 28 seconds
>>
>> Here is my translation for the following error message:
>>
>> CreateProcess error=740, L'opération demandée nécessite une élévation
>> CreateProcess error=740, The requested operation requires elevation
>>
>> Obviously, the program requires more privileges than my current user.
>> How do I fix this to complete the process and create the installer
>> file for Windows?
>
>
> Quoting from BUILDING.txt of Tomcat 8:
>
> [q]
>  2. If building the Windows installer
>
> If running the build in a UAC enabled environment, building the Windows
> installer requires elevated privileges. The simplest way to do this is to
> open the command prompt used for the build with the "Run as administrator"
> option.
> [/q]
>
> Also, do you really need the installer? You can skip it by setting the
> skip.installer property.
>
> Best regards,
> Konstantin 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

Building binary release on Windows 10

[Daniel Savard]

Hi everyone,

I am trying to perform a "build release" from source code for Tomcat
8.0.32 and I am running into the following error when it is time to
create the actual installer file.


BUILD FAILED
E:\Utilisateurs\dsavard\Projets\apache-tomcat-8.0.32-src\build.xml:2223:
Execute failed: java.io.IOException: Cannot run program
"E:\Utilisateurs\dsavard\Projets\apache-tomcat-8.0.32-src\output\dist\tempinstaller.exe"
(in directory 
"E:\Utilisateurs\dsavard\Projets\apache-tomcat-8.0.32-src\output\dist"):
CreateProcess error=740, L'opération demandée nécessite une élévation
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1047)
at java.lang.Runtime.exec(Runtime.java:617)
at 
org.apache.tools.ant.taskdefs.launcher.Java13CommandLauncher.exec(Java13CommandLauncher.java:58)
at org.apache.tools.ant.taskdefs.Execute.launch(Execute.java:428)
at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:442)
at org.apache.tools.ant.taskdefs.ExecTask.runExecute(ExecTask.java:629)
at org.apache.tools.ant.taskdefs.ExecTask.runExec(ExecTask.java:670)
at org.apache.tools.ant.taskdefs.ExecTask.execute(ExecTask.java:496)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:435)
at org.apache.tools.ant.Target.performTasks(Target.java:456)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1405)
at org.apache.tools.ant.Project.executeTarget(Project.java:1376)
at 
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1260)
at org.apache.tools.ant.Main.runBuild(Main.java:853)
at org.apache.tools.ant.Main.startAnt(Main.java:235)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:285)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:112)
Caused by: java.io.IOException: CreateProcess error=740, L'opération
demandée nécessite une élévation
at java.lang.ProcessImpl.create(Native Method)
at java.lang.ProcessImpl.(ProcessImpl.java:385)
at java.lang.ProcessImpl.start(ProcessImpl.java:136)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1028)
... 23 more

Total time: 1 minute 28 seconds

Here is my translation for the following error message:

CreateProcess error=740, L'opération demandée nécessite une élévation
CreateProcess error=740, The requested operation requires elevation

Obviously, the program requires more privileges than my current user.
How do I fix this to complete the process and create the installer
file for Windows?

Regards,
-
Daniel Savard

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Is IBM Right About Java?

[Daniel Savard]

2011/2/8 Robinson, Eric 

>
> Obviously I need to understand this better. If all instances are set to
> -Xmx512M and then one instance peaks to 512M and even tries to go above
> that (and therefore generates an OOME) how does that impact the other
> instances? Does an OOME mean there is no more memory available from the
> OS? I thought it just meant it had used the max memory allowed by the
> -Xmx setting. That should not cause a problem for other instances should
> it?
>
> --Eric

Eric,

what Chris is trying to explain is that a single instance using 512M
may not right then have adverse effects on others as long as the real
memory available is not exhausted and paging has started at the OS
level. However, increasing this limit for all instances may lead to a
situation where enough instances are claiming more memory at the same
time and beyond the physical memory available. At that point, the
system (OS) will start paging, provided you have paging space. It may
be still runnable and usable at this point until too many memory is
claimed and consume at the same time the OS enter the thrashing state.
Paging is not necessarily bad, thrashing is the point where paging
activity is so high no useful work but paging take place. The system
is no longer usable at this point.

Hope I was able to clarify Chris' point a little bit.

Regards,
--
-
Daniel Savard
CiDS Inc.
Montreal, QC
Canada

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat Consultant

[Daniel Savard]

That's an Opus Dei owned company, I fear. Unless you are seeking for
the anti-matter thing, you should rather than stay away of it.

2010/11/18 Martin Gainty 
>
> can we get someone from the vatican to translate?
>
> Martin Gainty
> __
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] RE: Tomcat Consultant

[Daniel Savard]

I think you are completely lost, none of the big 5 could bill below 200$/hr
and survive paying the big building and the big bosses, 100$/hr is what the
sub-contractors are billing them. I did work for one of these in the 90's
and they already billed between 200-300$/hr at that time, this is 20 years
ago.

And what are the lawyer's rates like in the commercial area? Don't you
believe having a working business infrastructure worth something or not? I
mean, lawyers are there to have the business legal terms working and the IT
consultant having the business infrastructure working. Does it compare or
not?

Daniel Savard

2010/9/29 Martin Gainty 

>
> i always wondered by the big 5 billable rate started at 100 /hr
>
> BTW: dont forgot your armani suit and the lamberghini!
> Martin Gainty
>

Re: Tomcat Consultant

[Daniel Savard]

Jorge,

Could you explain further what's the difference between an app
container and an app server? For me it seems pretty much the same.

Regards,
Daniel Savard

2010/9/24, Jorge Medina :
> Hey, you don't need a Big-5 consulting company.
> You need a a couple of experts: a networking guy and a Tomcat guy.
> But anyway, I'm sure a Fortune 500 have the money to overpay one of the
> Big-5.
>
> Now, from my understanding, Tomcat is only a web app container while
> Websphere is an application server.
> Therefore, depending on your application you may not be able to
> migrate it to Tomcat, but rather to Glassfish. Glassfish is also an
> application server.
>
> -Jorge
>
>
>
> On Fri, Sep 24, 2010 at 1:57 PM, Christopher Schultz
>  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> To whom it may concern,
>>
>> On 9/24/2010 1:25 PM, tdelesio wrote:
>>> My fortune 500 company is testing a pilot for switching over a J2EE
>>> web app over from Web Sphere application server to Tomcat and we are
>>> looking for a consultant to setup a crusted production instance of
>>> tomcat.
>>
>> Wait... are you testing it? If so, then you don't need anyone to set it
>> up, do you? By crusted, did you mean "trusted"?
>>
>>> Does anyone have any recommendations for a top notch consulting firm
>>> that could provide these services?
>>
>> I'm sure that any of the big-5 consulting companies would be very happy
>> to take way more money than is necessary to set up an instance of Tomcat
>> for you.
>>
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.10 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAkyc5o4ACgkQ9CaO5/Lv0PAjugCgiACwh5crjW+HXMKbzAWc+A27
>> dC4AoJjm6Dgs7FbMPrD3VBBdZl48VXas
>> =vADj
>> -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
>
>


-- 
-
Daniel Savard

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomat monitoring

[Daniel Savard]

We are not talking about SNMP monitoring, but about SNMP as a tool to
interface between monitoring of the JVM and applications and a
centralized manager or integration with a manager of managers in an
enterprise-wide picture.

Daniel Savard

2010/5/20 Ozgur Ozdemircili :
> Are we loosing the subject here a bit? While mentioning the "monitoring" I
> refer to JVM monitoring. Heap usage etc. not the snmp monitoring.
>
>
> Özgür Özdemircili
> http://www.acikkod.org
> Code so clean you could eat off it
>
>
> On Thu, May 20, 2010 at 12:32 PM, Daniel Savard 
> wrote:
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomat monitoring

[Daniel Savard]

So, decipher how the jconsole can be used as a monitoring tool? My
belief is it can be used to provide snmp agent services, but I have no
experience with it and I am curious to hear from others about it.

Daniel Savard

2010/5/20, Leon Rosenberg :
> On Thu, May 20, 2010 at 12:11 PM, Ozgur Ozdemircili
>  wrote:
>> Hi,
>>
>> It really seems like snmp monitoring software yet gives statistics about
>> Jvm.
>>
>> And yes Jconsole is a monitoring tool
>
> than we have different understanding of what a monitoring tool is ;-)
>
> but that's ok, we live in free countries and have the right to have
> own beliefs ;-)
>
> regards
> Leon
>
>>
>> Anyone that has used them in prod environement?
>>  <http://en.wikipedia.org/wiki/JConsole>
>> Özgür Özdemircili
>> http://www.acikkod.org
>> Code so clean you could eat off it
>>
>>
>> On Thu, May 20, 2010 at 12:04 PM, Leon Rosenberg
>> wrote:
>>
>>> Hello,
>>>
>>> never heard of javamelody before, but it looks like nagios ;-)
>>> Jconsole is definitely not a tool for monitoring.
>>>
>>> regards
>>> Leon
>>>
>>> On Thu, May 20, 2010 at 11:58 AM, Leon Rosenberg
>>>  wrote:
>>> > Hello,
>>> >
>>> > never heard of javamelody before, but it looks like nagios ;-)
>>> > Jconsole is definitely not a tool for monitoring.
>>> >
>>> > regards
>>> > Leon
>>> >
>>> > On Thu, May 20, 2010 at 10:42 AM, Ozgur Ozdemircili
>>> >  wrote:
>>> >> Hi,
>>> >>
>>> >> It seems ok yet the latest release was in 2006.
>>> >>
>>> >> Anyone using Java melody Jconsole in production?
>>> >>
>>> >> Salut!
>>> >> Özgür Özdemircili
>>> >> http://www.acikkod.org
>>> >> Code so clean you could eat off it
>>> >>
>>> >>
>>> >> On Wed, May 19, 2010 at 7:59 PM,  wrote:
>>> >>
>>> >>>
>>> >>> I use tomcat probe
>>> >>>
>>> >>> Try it its quite good
>>> >>> --Original Message--
>>> >>> From: Ozgur Ozdemircili
>>> >>> To: Tomcat Users List
>>> >>> ReplyTo: Tomcat Users List
>>> >>> Subject: Tomat monitoring
>>> >>> Sent: May 19, 2010 17:40
>>> >>>
>>> >>> Hi,
>>> >>>
>>> >>> I am looking for tomcat monitorization solutions.I am looking to
>>> >>> choose
>>> >>> between Jconsole and Javameleody
>>> >>>
>>> >>> Does anyone use one of those on their prod environment? Any problems
>>> with
>>> >>> either?
>>> >>>
>>> >>> Can you please share your experiences on the subject?
>>> >>>
>>> >>> Thanks!
>>> >>>
>>> >>>
>>> >>> Özgür Özdemircili
>>> >>> http://www.acikkod.org
>>> >>> Code so clean you could eat off it
>>> >>>
>>> >>>
>>> >>>
>>> >>> Sent from my BlackBerry® smartphone
>>> >>
>>> >
>>>
>>> -
>>> 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
>
>


-- 
-
Daniel Savard

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org