RE: location of tomcat-juli.jar

[Jeffrey Janner]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Friday, March 24, 2017 12:00 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: location of tomcat-juli.jar
> 
> On 24 March 2017 16:06:21 GMT+00:00, Jeffrey Janner
> <jeffrey.jan...@polydyne.com> wrote:
> >I was re-reading the RUNNING.txt  to see why I had to copy
> >tomcat-juli.jar to the CATALINA_BASE/bin directory instead of just
> >having it run out of CATALINA_HOME/bin.
> >It seemed annoying to me to have to copy it to all my  CATALINA_BASE
> >instances every time I upgraded, but I thought I ran into problems not
> >having it there.
> >Then I ran into this bit of documentation:
> >
> >In CATALINA_BASE:
> >
> >* bin  - Only the following files:
> >
> >   * setenv.sh (*nix) or setenv.bat (Windows),
> >   * tomcat-juli.jar
> >
> >
> >In CATALINA_BASE:
> >
> >* bin  - Only the following files:
> >
> >   * setenv.sh (*nix) or setenv.bat (Windows),
> >   * tomcat-juli.jar
> >
> >So I guess my question is, can I really just leave it out of my
> >CATALINA_BASE directory without causing any issues?
> >I want to say I had issues with it not being there, but cannot recall
> >what they were.
> >And if there is no difference, why make the suggestion in the
> >RUNNING.txt file at all?
> 
> You copied the wrong bits from RUNNING.txt
> 
> You can place the jar in CATALINA_HOME if you wish.
> 
> The historical reason for allowing both is if you want different
> implementations in different instances you need to put the right
> implementation JAR in CATALINA_BASE.
> 
> Mark
> 
Thanks Mark.  Thought I'd copied the right part for the second setting.  Here 
it is:

In CATALINA_HOME:

 * bin  - Startup and shutdown scripts

  The following files will be used only if they are absent in
  CATALINA_BASE/bin:

  setenv.sh (*nix), setenv.bat (Windows), tomcat-juli.jar

But, thanks for pointing out that if I don't need a specialized 
tomcat-juli.jar, it's OK to not copy to CATALINA_BASE.
It will make upgrades for my 100+ instances easier from now on.

Jeff

location of tomcat-juli.jar

[Jeffrey Janner]

I was re-reading the RUNNING.txt  to see why I had to copy tomcat-juli.jar to 
the CATALINA_BASE/bin directory instead of just having it run out of 
CATALINA_HOME/bin.
It seemed annoying to me to have to copy it to all my  CATALINA_BASE instances 
every time I upgraded, but I thought I ran into problems not having it there.
Then I ran into this bit of documentation:

In CATALINA_BASE:

* bin  - Only the following files:

   * setenv.sh (*nix) or setenv.bat (Windows),
   * tomcat-juli.jar


In CATALINA_BASE:

* bin  - Only the following files:

   * setenv.sh (*nix) or setenv.bat (Windows),
   * tomcat-juli.jar

So I guess my question is, can I really just leave it out of my CATALINA_BASE 
directory without causing any issues?
I want to say I had issues with it not being there, but cannot recall what they 
were.
And if there is no difference, why make the suggestion in the RUNNING.txt file 
at all?


Jeff

RE: AT WITS END regarding JVM arguments

[Jeffrey Janner]

Sorry for reviving an old thread, but this one caught my eye and I just had to 
make some, admittedly off-topic, comments per the concept of assumptions that 
pervaded a number of the posts here.

1) Having worked with all manner of IBM systems, as well as some environments 
you guys probably never heard of, why anyone would assume that the way you do 
it in an IBM environment is the way you would do it anywhere else is beyond me. 
 Heck, it often doesn't work the same way going from one IBM environment to 
another.  (obligatory IBM dig here)

2) Trying to implement something in the Windows environment, I would assume 
that someone would go ahead and use the fine Windows installer that someone has 
been kind enough to create and maintain over the years -- instead of installing 
from the zip file.  But then again, people on this list keep proving me wrong 
on this point.

3) Assuming something works on Windows, or any Microsoft implementation, the 
same way it works in other environments is also beyond me (obligatory Microsoft 
dig here)

4) Someone beginning to work in a new environment would read all available 
documentation on said environment as well as the related documentation of the 
application they wish to use that specifically targets that environment.  But 
that takes time, and with the sorry state of documentation these days, or lack 
thereof, it doesn't really surprise me that someone wouldn't.  Pretty soon, we 
will be at the other end of the spectrum from the old IBM 360/370 days, where 
documentation was not only voluminous, but also incomprehensible.  That end of 
the spectrum ends with "completely non-existent, good luck reading the source 
code".

It's been one of those weeks, and I had to get that off my chest.  I've been in 
this industry since 1982, and the only thing that's really changed is the 
names.  That and we can really mess things up much faster now.

Jeff



> -Original Message-
> From: James H. H. Lampert [mailto:jam...@touchtonecorp.com]
> Sent: Thursday, September 08, 2016 3:49 PM
> To: Tomcat Users List 
> Subject: Re: AT WITS END regarding JVM arguments
> 
> On 9/8/16, 12:23 PM, Christopher Schultz wrote:
> 
> > Would you care to create an account on the Tomcat Wiki[1] and post
> > your CL program? It may help someone else running in similar
> > environments. In fact, if you want to write-up a whole page about
> > "Running Tomcat on IBM Midrange", you could include that as well as
> > any other nuggets you've collected throughout the years.
> 
> Hmm. Looks like there are scant resources there for Tomcat on Midrange.
> (I bookmarked a page at mysamplecode.com that was very helpful with my
> first few installations.)
> 
> I now have a Tomcat Wiki account, but it appears I need to request
> posting privileges (apparently via this very list?) in order to receive
> them.
> 
> I'm enrolled as "JamesLampert"; I'll see what I can put together offline
> until I'm informed that I have posting privileges on the Wiki.
> 
> --
> JHHL
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Apache TomCat 5.5

[Jeffrey Janner]

Mary -
First, sorry for the top-post.

I noticed in your original post that you have upgraded to the latest Java 8, 
and nearly latest Windows version (at least new than the release available when 
Tomcat 5.5 was first available).  I don't understand why you can't just go 
ahead and upgrade to the latest Tomcat 8 or 8.5 implementation.  As others have 
said, it is quite likely that your application will run just fine.
Without more details of your exact implementation environment, I can't give 
full advice, but here are some things to take into account:

1) If you are terminating SSL at the IIS7 client interface, then that is where 
you need to enable HSTS. It only needs to be on the IIS7-Tomcat conversation if 
that is also using SSL on its linkage (not normally needed for an internal 
network, but your requirements may specify otherwise).  Strip it out of headers 
on the way to Tomcat and add it back on the way to client if necessary.

2) When going from such an old Version of Tomcat to a newer one, be aware that 
Tomcat configuration files and options HAVE changed.  You cannot just copy 
server.xml, context.xml, etc. files from the old version to the new.  You must 
migrate your settings to the new versions.  This is not that difficult or 
time-consuming, but it is best to do this manually.

3) Beware of any changes to provided valves/filters that you rely on.  Changes 
to those in new versions may require you to handle them differently.

4) Do this all in a test/dev environment, possibly several times, before even 
thinking about changing production.

5) If the addition of an additional/unknown HTTP header is causing problems 
with your backend processing, then you have more problems than you think you 
do. You application is in violation of the most basic tenets of the HTTP 
protocol stack, as those headers should just be ignored according to the 
protocol.  Your application may stop working correctly in the next few months 
even without you doing anything to your current setup.

Respectfully,
Jeff


> -Original Message-
> From: Pham, Mary (NIH/OD/ORS) [E] [mailto:maryp...@mail.nih.gov]
> Sent: Wednesday, September 21, 2016 9:52 AM
> To: 'Tomcat Users List' 
> Subject: RE: Apache TomCat 5.5
> 
> Thank you.  Chris, Chuck, Andre, Mark who had answered and I've done
> this far.
> My report.
> - I installed the "URL rewrite" module on IIS 7.  To make short, it
> worked.  http to https redirected then enforced hsts on the IIS site.
> - but broke all the scripts run on Tomcat due to Strick Transport
> Security when HTTPS.
> - so I have to disable in/outbound of URL rewrite.
> Back to square one.  We will not be able to upgrade Tomcat at this time.
> 
> Please help.
> 
> -Mary
> 
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Thursday, September 15, 2016 11:01 AM
> To: Tomcat Users List 
> Subject: Re: Apache TomCat 5.5
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> André,
> 
> On 9/14/16 7:04 PM, André Warnier (tomcat) wrote:
> > Mary, have a look here :
> > http://tomcat.apache.org/whichversion.html Tomcat 5.5 was first
> > released about 10 years ago, and the last modification to it was in
> > 2012. The current "stable" version is Tomcat 8.5.5.
> >
> > For Open Source and free software such as Apache Tomcat, that means
> > that your chances of getting support and help for such an old version
> > are really not good, because most of the people which would be able to
> > help you probably do not run that version anywhere anymore. Even the
> > documentation is not directly available on-line anymore.
> >
> > Regarding your particular issue, it is even possible that the
> > requirement which you are mentioning is younger than Tomcat 5.5 and
> > cannot be met by such an old software version. It is even likely that,
> > considering the age of your Tomcat and the age of the Java JVM it is
> > probably running under, there are a whole lot of other security issues
> > with your server, which make it impossible to make it "secure as the
> > government requires".
> >
> > What I am saying is that you are probably wasting your time, and
> > ultimately your employer's time, with this approach.
> >
> > You seem to mention below that you are using Tomcat "with IIS".
> > Maybe this IIS is a front-end to Tomcat, and users access Tomcat
> > always through IIS. If so, then as long as the connection between IIS
> > and Tomcat is secure (e.g. they run on the same host), then you should
> > probably take care of the SSL/HTTPS (and header) aspect on the IIS
> > front-end. That is, if you /really/ cannot upgrade Tomcat and if your
> > applications /really/ do not run under a newer version of Tomcat and
> > Java.
> 
> HSTS is just an HTTP header thing. It can be deployed on any version of
> anything basically back until the beginning of (HTTP) time.
> 
> It's slightly easier to do with more recent Tomcats 

RE: Restrict access to manager app by IP

[Jeffrey Janner]

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Tuesday, September 06, 2016 12:30 PM
> To: Tomcat Users List 
> Subject: Re: Restrict access to manager app by IP
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Yuval,
> 
> On 9/2/16 9:29 AM, Yuval Schwartz wrote:
> > Thanks. I'll give it a shot and let you guys know how it goes. Any
> > input on whether I should put this in my applications context.xml
> > or in my [host] directory?
> 
> I would do it in the application. Unless you have a particular reason
> to manually-place the application's context.xml file into
> conf/[engine]/[host]/[app].xml, allow Tomcat to do that for you.
> 
> - -chris
 
Chris -

Isn't the Tomcat "/manager" an app separate from the user's webapp?  Thus the 
need for the manager.xml in conf/[engine]/[host] directory?

Yuval: what you were proposing is the way I have done it.  Just make sure you 
specify the regular expression correctly.

Jeff


> 
> > On Fri, Sep 2, 2016 at 4:24 PM, Kreuser, Peter
> >  wrote:
> >
> >> Hi Yuval,
> >>
> >>
> >>> -Ursprüngliche Nachricht- Von: Yuval Schwartz
> >>> [mailto:yuval.schwa...@gmail.com] Gesendet: Freitag, 2.
> >>> September 2016 13:28 An: Tomcat Users List Betreff: Restrict
> >>> access to manager app by IP
> >>>
> >>> Tomcat: 8.0.22 JDK: 1.8.0_05
> >>>
> >>> Hello,
> >>>
> >>> I am currently running a web application.
> >>>
> >>> I would like to restrict access to the manager app (it is
> >>> currently
> >> being hit by spammers every so often who are unable to connect
> >> (get a message "...an attempt was made to authenticate the locked
> >> user")).
> >>>
> >>> I was thinking of adding a "manager.xml" file to
> >>> $CATALINA_BASE/conf/[enginename]/[hostname]/
> >> that will contain the following context container:
> >>>
> >>>   >> className="org.apache.catalina.valves.RemoteAddrValve"
> >>> allow="[my_ip]"/> 
> >>>
> >>> Is this the correct way to achieve my goal of limiting access
> >>> to the
> >> manager app to only my IP.
> >>>
> >>> Of course, I do not want the rest of my webapp's access limited
> >>> (which
> >> is on the ROOT path). I only want access to the manager app
> >> limited.
> >>>
> >>> (I know I can also place the context container in my webapp's
> >> META-INF/context.xml file, is there any preference to doing this
> >> over what I suggested above?)
> >>>
> >>> Thank you _
> >>>
> >>
> >> That's the proposed solution for it. I don't think that you need
> >> the docbase - unless you don't use the default location.
> >>
> >> I think you will have to quote the . in the ip with backslash,
> >> like  >> className="org.apache.catalina.valves.RemoteAddrValve"
> >> allow="10\.100\.17\.33|10\.100\.88\.92" />
> >>
> >> Best regards
> >>
> >> Peter
> >>
> >
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBCAAGBQJXzv0QAAoJEBzwKT+lPKRYzmAP/j8dKzBSD6tVZ/BgIy+zMugt
> sSKse+GWF52mPs3bhTx6Mghil0pLxCL8kROHUVVPrq8DknGf81qaSsxCqEgi7r6r
> ZnK8YYG0GAVFbUjDHcBGDtD4jGV+S7Vwfp7CxJqdpuM2XAzU/EX+A2vwsDxm96Hg
> bNhZ0Dv1xeErKzH+X6zcEeqSGXS411dxfH86zpoQrispygSEzFQ4eZ+qXcg/39rO
> ukN2L6gkeN0wo4rqLTTIEOz/qoIqWjB7Oi+DQFEZWxSQuFeM2XHZ6XcVR7W6D+zN
> AmiKuFQp6jrsmnpIaWWdLk5BGAogb0aGTE6sgBhYuutLvB9JA4XqCq57fzlR8y58
> eR2hoTlEdqs8hSvllOBpyYoZdoOlpdCEHoTc/6LEMP+JIFL7QAy+/wQNXJv8XeQ7
> BKFlkSceNvRWLdYFi4q2aVIgr1ZtgzP5VwZjMNVyeO5/oYzKp0PS7+3s52rBs3At
> Jj7WuqUDob6ZMp5Q4DgM2SCK1xe0Q1bgooJMC8zaxyyzfPcY1i3DiIls/RTXPd47
> fGnHEIHSrkDbsMq3Jxr+3pCWukZqRsnWcMIzORRHWEGlDF2NidnC5h1M7y0p7yhO
> erjwuLmDwwNZzpWMhjjMPB6avoiy46wa+lhIjbCyuCLiJGp1gIkFfcIUsvXxkKFq
> BYUo344Ks4Vjvk40V1Nz
> =gIMk
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Using server Web.xml Mime Types Data

[Jeffrey Janner]

George,
As I recall, anything in the server's web.xml is merged with the application's 
web.xml unless overridden by the applications own settings, i.e. if not defined 
in the app web.xml file.
Was there something specific you were asking that didn't come across in your 
question?
Jeff

> -Original Message-
> From: George Sexton [mailto:geor...@mhsoftware.com]
> Sent: Tuesday, September 06, 2016 6:59 PM
> To: Tomcat Users List 
> Subject: Using server Web.xml Mime Types Data
> 
> Is there any easy way that I can use the mime types in the Tomcat server
> level web.xml file?
> 
> I know I can parse the XML myself, I was just wondering if there's a way
> to get the data already defined.
> 
> 
> --
> George Sexton
> *MH Software, Inc.*
> Voice: 303 438 9585
> http://www.connectdaily.com

SSL/TLS and ciphers vulnerability

[Jeffrey Janner]

Hi folks,

I've been off the list for a bit, getting ducks in a row here and everything.
I noticed a number of posts about SSL & TLS security settings lately and I 
wanted to point out that maintaining your SSL configurations is an on-going 
processes.
New exploits are discovered and released quite often, and often the fault lies 
with a cipher and not necessarily an overall SSL/TLS protocol.
So using a cipher list like "all except RC4" is probably not sufficient anymore.
And what is secure may depend completely on the SSL/TLS software you use, be it 
OpenSSL or Java's built in SSL libraries.
For example, with OpenSSL, you should be using 1.0.1t or higher, and even then 
only TLS1.2 with a handful of ciphers.
I'm not sure what the recommended options for java's libraries are at the 
moment.
A really good, free tool is Qualys' SSL Labs server test tool located at: 
https://www.ssllabs.com/ssltest/
Run that against your implementation and follow its recommendations.

Of course, at the end of the day, it will be up to you and your firm to decide 
what risks you are willing to take with your SSL communications and whether or 
not you need to support insecure browsers, i.e. browsers that cannot negotiate 
up to the most secure protocol and ciphers.

Jeffrey Janner
p.s. Qualys also has a test suite for the browsers that you use.

RE: Multiple domian names one web site different content

[Jeffrey Janner]

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Friday, March 04, 2016 3:36 PM
> To: Tomcat Users List 
> Subject: Re: Multiple domian names one web site different content
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Jose,
> 
> On 3/4/16 3:46 PM, Jose María Zaragoza wrote:
> > Maybe my question does't have to do with current thread ( an
> > probably doesn't have any sense at all) but :
> >
> > would be possible to define "VirtualHost" according the destination
> > port ? I know that VirtualHost diferent domain name, but i want to
> > keep the same domain name and to define 2 connectors , listening on
> > 8080 and 8081 Requests to 8080 go to /webapps-app1 and requests to
> > 8081 go to /webapps-app2
> >
> > is it possible in a only one Tomcat instance ? or  I need to
> > configure 2 tomcat instances ?
> 
> You would need to configure Tomcat to listen on two different
> interfaces (or two different ports as you have above), plus have those
>  in separate s in Tomcat's configuration so their
> s wouldn't interfere.
> 
> More trouble than it's worth IMO.
> 
> - -chris

Chris's approach is correct.  That's the only way to separate  by 
.
If you are stuck with that approach for some reason, it's what you'd need to 
do.  But might as well have two separate tomcat instances.  After all, that is 
what setting up multiple  configs is really accomplishing.
The only advantage this gives you is if you are tight on memory and need to 
share the JVM's heap space between the webapp. (note: this only shares the 
memory, neither has access to the other's objects.)
Used to do this for some smallish webapps on Windows, primarily to give each 
webapp/host it's own connector set for 80/443 without having to do dances 
around that default host stuff.
Nowadays, I'm on linux with a load-balancing front-end that can properly serve 
the correct SSL certificate, so it's not so important.

Jeff

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

RE: Virtual Hosting, HTTP 302 to HTTPS?

[Jeffrey Janner]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Monday, February 01, 2016 9:21 AM
> To: Tomcat Users List 
> Subject: Re: Virtual Hosting, HTTP 302 to HTTPS?
> 
> On 1 February 2016 14:07:57 GMT+00:00, "Björn Raupach" 
> wrote:
> >Dear group,
> >
> >I have two web applications (a,b) that are both reachable via
> >subdomains:
> >
> >a.example.com 
> >b.example.com 
> >
> >For b.example.com  exists a SSL certificate.
> >a.example.com  does not need SSL.
> >The HTTPS connector uses a a Java keystore with the certificate.
> >
> >I configured Apache Tomcat 8.0.20 with Virtual Hosting.
> >
> >CATALINA_HOME/webapps_a
> >CATALINA_HOME/webapps_b
> >
> >The server.xml has been adjusted.
> >
> >
> >
> >
> >   ...
> > 
> >
> >
> >   ...
> > 
> >
> >
> >
> >Both web apps are deployed using ROOT.war. They get unpacked and there
> >are no errors in the log files.
> >
> >Here is my problem. b works fine, but I can't reach a.
> >
> >curl -I http://a.example.com 
> >HTTP/1.1 302 Found
> >Server: Apache-Coyote/1.1
> >Cache-Control: private
> >Expires: Thu, 01 Jan 1970 01:00:00 CET
> >Location: https://a.example.com 
> >Content-Length: 0
> >Date: Mon, 01 Feb 2016 13:52:32 GMT
> >
> >curl -I http://b.example.com 
> >HTTP/1.1 302 Found
> >Server: Apache-Coyote/1.1
> >Cache-Control: private
> >Expires: Thu, 01 Jan 1970 01:00:00 CET
> >Location: https://b.example.com 
> >Content-Length: 0
> >Date: Mon, 01 Feb 2016 13:52:54 GMT
> >
> >The redirect sets Location to https. I know this can't work because I
> >have no
> >certificate for srv.grasmueck.de  nor do I
> >need https.
> >
> >And I see the web application `b` instead of `a` despite the error.
> >
> >Do I need a Apache HTTPD fronted?
> 
> No.  The name of your virtual host (or one of its aliases) must match
> the host header. If they don't match the default host will be used.
> 
> Given that you've already told us one of the real host names, you might
> as well show us the real configuration and the real request if you need
> help spotting the configuration error.
> 
> Mark
> 
Since the information provided shows that both URLs are responding with a 302 
redirect to the HTTPS connector with the same hostname as provided, I'd say 
that his server.xml configuration is working correctly.
Obviously, there is something in both webapps that is forcing the redirect.
Might I suggest the OP take a look at the web.xml file for the A host to see if 
he can see that it is indeed requesting the redirect?  (hint: 
 section.)
Jeff

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
> Sent: Thursday, September 10, 2015 12:01 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: RE: Multiple JSESSIONID cookies being presented.
> 
> > From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
> > Subject: RE: Multiple JSESSIONID cookies being presented.
> 
> > I checked the error.jsp file and it does have session=true set, and if
> the icon file
> > is missing, the error.jsp is definitely being sent.
> 
> > So it looks like the possible solutions are:
> > 1) provide a favicon.ico file.
> > 2) remove the session=true setting from the error page.
> > 3) somehow not send the error.jsp when a sub-link (image, script,
> etc.) results in a 404.
> > 4) Have the login page of APP2 provide it's own icon  directive
> (it doesn't currently
> > have one.)
> 
> Why would you ever want your error.jsp to create a session?  Sounds like
> an easy DoS attack to me.
> 
>  - Chuck
> 
Programmers.  What more do I need to say


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

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Thursday, September 10, 2015 2:24 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: Multiple JSESSIONID cookies being presented.
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Jeffrey,
> 
> On 9/10/15 12:26 PM, Jeffrey Janner wrote:
> > Thanks for all the help guys. I think I've sussed out what is
> > going on here.  Now just have to get the Dev guys to address it.
> >
> > After spending a good bit of time clearing and watching cookies
> > and access logs, both with and without a favicon.ico file, I found
> > that the doubling was happening only if the file was missing.  I
> > checked the error.jsp file and it does have session=true set, and
> > if the icon file is missing, the error.jsp is definitely being
> > sent.
> >
> > So it looks like the possible solutions are: 1) provide a
> > favicon.ico file.
> 
> This fixes the symptom, not the problem. You'll get the same problem
> with clients who request /apple-touch-icon.png, /robots.txt, or just
> about any other file that ends up resulting in a 404. This could be
> something from within the application itself, and will (apparently)
> cause mass confusion.
> 
> > 2) remove the session=true setting from the error page.
> 
> This is the right answer. Do you really need the session in error.jsp?
> 
> > 3) somehow not send the error.jsp when a sub-link (image, script,
> > etc.) results in a 404.
> >
> > 4) Have the login page of APP2 provide it's own icon 
> > directive (it doesn't currently have one.)
> 
> > Any other options?
> 
> If you absolutely need access to the session in your error.jsp file,
> you can do this:
> 
> 
> <%
>   HttpSession session = request.getSession(false);
> 
>   ...
> %>
> 
> This will prevent sessions from being created when there isn't already
> a session. You'll have to check the code for error.jsp to make sure
> that no code uses the session before checking it for null -- because
> session="true" guarantees that the "session" reference will be non-null.
> 
> That will allow you to use session information in error.jsp if a
> session already exists, but not create a superfluous session when one
> does not (yet) exist.
> 
Thanks for the above Chris. I passed the information on to someone who can get 
it implemented.

> Back to Tomcat's session management: Tomcat *can* handle this
> situation properly: it will try all JSESSIONID cookies it gets to find
> a valid one in the current web application. So, multiple JSESSIONID
> cookies won't confuse Tomcat. Some other component must be
> mis-understanding the session identifier in some way.
> 
> - -chris

Yes, I don't think it's bothering Tomcat at all. We've never experienced a 
problem with direct-to-tomcat configurations, and we've had this setup for 
years.
We recently implemented an HaProxy front-end using stick-tables and think it's 
potentially confusing HaProxy. But I can't swear to that, because I did find a 
problem with how jvmRoute was being applied, resulting in both servers 
providing the same value, so that could have been the underlying problem all 
along.
However, the session on error is a basics issue that needs to be resolved.
Thanks again.  I think we are done here.
Jeff

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, September 09, 2015 1:50 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: Multiple JSESSIONID cookies being presented.
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Jeffrey,
> 
> On 9/9/15 12:08 PM, Jeffrey Janner wrote:
> >> -Original Message- From: Caldarale, Charles R
> >> [mailto:chuck.caldar...@unisys.com] Sent: Tuesday, September 08,
> >> 2015 4:58 PM To: Tomcat Users List <users@tomcat.apache.org>
> >> Subject: RE: Multiple JSESSIONID cookies being presented.
> >>
> >>> From: Jose María Zaragoza [mailto:demablo...@gmail.com]
> >>> Subject: Re: Multiple JSESSIONID cookies being presented.
> >>
> >>>> Thanks for the clarification of what's supposed to happen on
> >> receipt, Jose.
> >>>> However, I am describing what happens on first contact from
> >>>> the
> >> client to the server.
> >>>> The browser sends https://hostname/APP2, and Tomcat returns:
> >>>> JSESSIONID=, path=/and   JSESSIONID=,
> >>>> path=/APP2/
> >>
> >>> Indeed, it doesn't make sense for me to return different id (
> >>>  ,  ) if you are accesing to only one context (/APP2)
> >>
> >>> Are you sure that your webapp deployed in /APP2 is not accesing
> >>> to resources ( session-aware resources as JSP, servlet, .. .I
> >>> mean) stored in ROOT context ?
> >>
> >> As I think someone previously mentioned, the client (browser) may
> >> well be sending an unsolicited request to the default webapp,
> >> such as when trying to retrieve favicon.ico.  You might want to
> >> run Fiddler or Wireshark on the client to see exactly what's
> >> being sent to the server.
> >>
> >
> > And there's no way to keep a browser from asking for the
> > favicon.ico file from the root. We don't have one, so I would
> > expect a 404 is sent, which looking at the access log file is what
> > happens. However, is this the issue?  I tested this doing a manual
> > https://hostname/favicon.ico and see that we also return our root
> > app's error page. We also seem to be doing that for the
> > auto-generated request, judging by the bytes returned value, even
> > though it won't get displayed. And I bet that the error page is
> > setting the session cookie for some reason. Does that sound
> > reasonable? Is my solution just providing a favicon.ico file?
> 
> Can you make sure that all cookies have been cleared from the test
> client and then explain exactly when Tomcat sends the Set-Cookie headers
> ?
> 
> When we had this problem, it was usually because the client had old
> funky session ids in its cookie jar and the solution was to blow them
> all away and start-over fresh. (Then fix our software so it wouldn't
> happen anymore.)
> 
> - -chris
Thanks for all the help guys. I think I've sussed out what is going on here.  
Now just have to get the Dev guys to address it.
After spending a good bit of time clearing and watching cookies and access 
logs, both with and without a favicon.ico file, I found that the doubling was 
happening only if the file was missing.  I checked the error.jsp file and it 
does have session=true set, and if the icon file is missing, the error.jsp is 
definitely being sent.
So it looks like the possible solutions are:
1) provide a favicon.ico file.
2) remove the session=true setting from the error page.
3) somehow not send the error.jsp when a sub-link (image, script, etc.) results 
in a 404.
4) Have the login page of APP2 provide it's own icon  directive (it 
doesn't currently have one.)

Any other options?
Jeff

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

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Igor Cicimov [mailto:icici...@gmail.com]
> Sent: Tuesday, September 08, 2015 10:09 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: RE: Multiple JSESSIONID cookies being presented.
> 
> On 09/09/2015 7:13 AM, "Jeffrey Janner" <jeffrey.jan...@polydyne.com>
> wrote:
> >
> > > -Original Message-
> > > From: Jose María Zaragoza [mailto:demablo...@gmail.com]
> > > Sent: Tuesday, September 08, 2015 9:22 AM
> > > To: Tomcat Users List <users@tomcat.apache.org>
> > > Subject: Re: Multiple JSESSIONID cookies being presented.
> > >
> > > 2015-09-08 15:51 GMT+02:00 Jeffrey Janner
> <jeffrey.jan...@polydyne.com>:
> > > >> -Original Message-
> > > >> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> > > >> Sent: Friday, September 04, 2015 12:46 PM
> > > >> To: Tomcat Users List <users@tomcat.apache.org>
> > > >> Subject: Re: Multiple JSESSIONID cookies being presented.
> > > >>
> > > >> -BEGIN PGP SIGNED MESSAGE-
> > > >> Hash: SHA256
> > > >>
> > > >> Jeffrey,
> > > >>
> > > > Now, it's been doing this since at least Tomcat 6, I have one
> running
> > > now, and I've never had a problem with it using direct connections.
> But
> > > now we are front-ending with HaProxy and going to two backend
> tomcats,
> > > and using the JSESSIONID to support sticky-sessions.  I'm afraid the
> > > multiple cookies is confusing HaProxy. (Yes, I'm going to ask that
> user
> > > community.)
> > > > Jeff
> > >
> > >
> > > You could use another cookie to implement stickyness
> > >
> > > "You can add a cookie SOME-COOKIE-NAME prefix directive into the
> > > backend. Then simply add the cookie directive within each server.
> Then
> > > HAProxy will append a cookie (or add onto an existing one) a
> > > identifier for each server. This cookie will be sent back in
> > > subsequent requests from the client, letting HAProxy know which
> server
> > > to send the request to. This looks like the following:"
> > >
> > > backend nodes
> > > # Other options above omitted for brevity
> > >  cookie SRV_ID prefix
> > > server web01 127.0.0.1:9000 cookie check
> > > server web02 127.0.0.1:9001 cookie check
> > > server web03 127.0.0.1:9002 cookie check
> > >
> > >
> > > https://serversforhackers.com/load-balancing-with-haproxy
> > >
> > Thanks Jose.  We considered that, as well as having HaProxy just
> generate
> its own sticky-session cookie, but it seemed like a better idea to just
> let
> Tomcat handle it and use stick-tables. We are moving towards a
> fully-clustered tomcat, so already having the config in place such that
> we
> only have to turn off the stick-tables and we'd be set to go. I'll
> eventually be supporting a fairly large number of backends and don't
> want
> to make the configuration of new ones very complicated. Making them
> simple
> and pushing the complication down to the tomcat level just seemed to
> make
> more sense.
> 
> If using more than one haproxy inserting its own cookie is much better
> solution since you don't have to sync the stick tables between the lb's.
> 
> > In fact, I've parameterized the jvmRoute setting in the Tomcat
> server.xml
> and use the setenv.sh script to calculate the value based on the server
> the
> Tomcat is running on.
> > If only there were some way to have HaProxy read an already existing
> suffix in the cookie string, like httpd, my life would be perfect.
> > Jeff
Thanks Igor.  We may have to look into that in the future. We are running 
multiple HaProxy servers relying on Round robin DNS, so we need to have some 
method of insuring a consistent cookie between the two HaProxy servers. 
Thanks again.

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
> Sent: Tuesday, September 08, 2015 4:58 PM
> To: Tomcat Users List 
> Subject: RE: Multiple JSESSIONID cookies being presented.
> 
> > From: Jose María Zaragoza [mailto:demablo...@gmail.com]
> > Subject: Re: Multiple JSESSIONID cookies being presented.
> 
> > > Thanks for the clarification of what's supposed to happen on
> receipt, Jose.
> > > However, I am describing what happens on first contact from the
> client to the server.
> > > The browser sends https://hostname/APP2, and Tomcat returns:
> > > JSESSIONID=, path=/and   JSESSIONID=, path=/APP2/
> 
> > Indeed, it doesn't make sense for me to return different id (  ,
> >  ) if you are accesing to only one context (/APP2)
> 
> > Are you sure that your webapp deployed in /APP2 is not accesing to
> > resources ( session-aware resources as JSP, servlet, .. .I mean)
> > stored in ROOT context ?
> 
> As I think someone previously mentioned, the client (browser) may well
> be sending an unsolicited request to the default webapp, such as when
> trying to retrieve favicon.ico.  You might want to run Fiddler or
> Wireshark on the client to see exactly what's being sent to the server.
> 

And there's no way to keep a browser from asking for the favicon.ico file from 
the root. 
We don't have one, so I would expect a 404 is sent, which looking at the access 
log file is what happens.
However, is this the issue?  I tested this doing a manual 
https://hostname/favicon.ico and see that we also return our root app's error 
page. We also seem to be doing that for the auto-generated request, judging by 
the bytes returned value, even though it won't get displayed.
And I bet that the error page is setting the session cookie for some reason.
Does that sound reasonable?  
Is my solution just providing a favicon.ico file?
Jeff

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

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Jose María Zaragoza [mailto:demablo...@gmail.com]
> Sent: Tuesday, September 08, 2015 9:22 AM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: Multiple JSESSIONID cookies being presented.
> 
> 2015-09-08 15:51 GMT+02:00 Jeffrey Janner <jeffrey.jan...@polydyne.com>:
> >> -Original Message-
> >> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> >> Sent: Friday, September 04, 2015 12:46 PM
> >> To: Tomcat Users List <users@tomcat.apache.org>
> >> Subject: Re: Multiple JSESSIONID cookies being presented.
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA256
> >>
> >> Jeffrey,
> >>
> > Now, it's been doing this since at least Tomcat 6, I have one running
> now, and I've never had a problem with it using direct connections.  But
> now we are front-ending with HaProxy and going to two backend tomcats,
> and using the JSESSIONID to support sticky-sessions.  I'm afraid the
> multiple cookies is confusing HaProxy. (Yes, I'm going to ask that user
> community.)
> > Jeff
> 
> 
> You could use another cookie to implement stickyness
> 
> "You can add a cookie SOME-COOKIE-NAME prefix directive into the
> backend. Then simply add the cookie directive within each server. Then
> HAProxy will append a cookie (or add onto an existing one) a
> identifier for each server. This cookie will be sent back in
> subsequent requests from the client, letting HAProxy know which server
> to send the request to. This looks like the following:"
> 
> backend nodes
> # Other options above omitted for brevity
>  cookie SRV_ID prefix
> server web01 127.0.0.1:9000 cookie check
> server web02 127.0.0.1:9001 cookie check
> server web03 127.0.0.1:9002 cookie check
> 
> 
> https://serversforhackers.com/load-balancing-with-haproxy
> 
Thanks Jose.  We considered that, as well as having HaProxy just generate its 
own sticky-session cookie, but it seemed like a better idea to just let Tomcat 
handle it and use stick-tables. We are moving towards a fully-clustered tomcat, 
so already having the config in place such that we only have to turn off the 
stick-tables and we'd be set to go. I'll eventually be supporting a fairly 
large number of backends and don't want to make the configuration of new ones 
very complicated. Making them simple and pushing the complication down to the 
tomcat level just seemed to make more sense.
In fact, I've parameterized the jvmRoute setting in the Tomcat server.xml and 
use the setenv.sh script to calculate the value based on the server the Tomcat 
is running on.
If only there were some way to have HaProxy read an already existing suffix in 
the cookie string, like httpd, my life would be perfect.
Jeff

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

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Jose María Zaragoza [mailto:demablo...@gmail.com]
> Sent: Tuesday, September 08, 2015 9:08 AM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: Multiple JSESSIONID cookies being presented.
> 
> 2015-09-08 15:51 GMT+02:00 Jeffrey Janner <jeffrey.jan...@polydyne.com>:
> >> -Original Message-
> >> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> >> Sent: Friday, September 04, 2015 12:46 PM
> >> To: Tomcat Users List <users@tomcat.apache.org>
> >> Subject: Re: Multiple JSESSIONID cookies being presented.
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA256
> >>
> >> Jeffrey,
> >>
> >> On 9/4/15 12:37 PM, Jeffrey Janner wrote:
> >> > I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm
> >> > also seeing this on Windows (version doesn't matter), with Tomcat
> >> > 7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java 7U51.
> >> >
> >> > I have 2 contexts installed in Tomcat, one is ROOT, the other
> >> > APP2. Both contexts start off at a login screen unique to the
> >> > context and provided by it (not using container auth).
> >> >
> >> > When I connect to ROOT, no problem, but when I connect to APP2, I
> >> > get 2 JSESSIONID cookies, one with the path "/" and the other with
> >> > the path "/APP2/".
> >>
> >> I would expect this behavior: you have one ROOT app (cookie path=/)
> >> and one APP2 app (cookie path=/APP2). Your browser will send both
> >> cookies to /APP2 because / is a prefix of /APP2.
> >>
> > Chris -
> > I wanted to come back to this case.
> > Why is the above "expected behavior"?
> > The client is connecting directly as "https://hostname/APP2; and never
> going directly to the ROOT app, yet gets both JSESSIONIDs from Tomcat on
> first connection.  To me, this seems like a bug.
> > Only being an admin, I've not fully read the spec, so not sure if the
> above is really expected behavior.
> 
> 
> http://www.ietf.org/rfc/rfc2109.txt
> 
> The following rules apply to choosing applicable cookie-values from
>among all the cookies the user agent has.
> 
> Domain Selection
> The origin server's fully-qualified host name must domain-match
> the Domain attribute of the cookie.
> 
>Path Selection
> The Path attribute of the cookie must match a prefix of the
> request-URI.
> 
>Max-Age Selection
> Cookies that have expired should have been discarded and thus
> are not forwarded to an origin server.
> 
>If multiple cookies satisfy the criteria above, they are ordered in
>the Cookie header such that those with more specific Path attributes
>precede those with less specific.  Ordering with respect to other
>attributes (e.g., Domain) is unspecified.
> 
> 
> 
Thanks for the clarification of what's supposed to happen on receipt, Jose.
However, I am describing what happens on first contact from the client to the 
server.
The browser sends https://hostname/APP2, and Tomcat returns:
JSESSIONID=, path=/and   JSESSIONID=, path=/APP2/

My contention is that it shouldn't be sending the first one, since it should 
never route the request to the ROOT app, so it should not be generating a 
cookie for it.

However, taking what you say above at face value, are you saying that HaProxy 
should only be forwarding the cookie with path=/APP2/ or should it forward all 
of them and let Tomcat figure it out.

Jeff

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Friday, September 04, 2015 12:46 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: Multiple JSESSIONID cookies being presented.
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Jeffrey,
> 
> On 9/4/15 12:37 PM, Jeffrey Janner wrote:
> > I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm
> > also seeing this on Windows (version doesn't matter), with Tomcat
> > 7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java 7U51.
> >
> > I have 2 contexts installed in Tomcat, one is ROOT, the other
> > APP2. Both contexts start off at a login screen unique to the
> > context and provided by it (not using container auth).
> >
> > When I connect to ROOT, no problem, but when I connect to APP2, I
> > get 2 JSESSIONID cookies, one with the path "/" and the other with
> > the path "/APP2/".
> 
> I would expect this behavior: you have one ROOT app (cookie path=/)
> and one APP2 app (cookie path=/APP2). Your browser will send both
> cookies to /APP2 because / is a prefix of /APP2.
> 
Chris -
I wanted to come back to this case. 
Why is the above "expected behavior"?
The client is connecting directly as "https://hostname/APP2; and never going 
directly to the ROOT app, yet gets both JSESSIONIDs from Tomcat on first 
connection.  To me, this seems like a bug.
Only being an admin, I've not fully read the spec, so not sure if the above is 
really expected behavior.
Now, it's been doing this since at least Tomcat 6, I have one running now, and 
I've never had a problem with it using direct connections.  But now we are 
front-ending with HaProxy and going to two backend tomcats, and using the 
JSESSIONID to support sticky-sessions.  I'm afraid the multiple cookies is 
confusing HaProxy. (Yes, I'm going to ask that user community.)
Jeff

Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

Hi folks,
I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm also seeing 
this on Windows (version doesn't matter), with Tomcat 7.0.57 and Java 7u71, and 
Tomcat 6.0.43 and Java 7U51.
I have 2 contexts installed in Tomcat, one is ROOT, the other APP2.  Both 
contexts start off at a login screen unique to the context and provided by it 
(not using container auth).
When I connect to ROOT, no problem, but when I connect to APP2, I get 2 
JSESSIONID cookies, one with the path "/" and the other with the path "/APP2/".
On the Windows implementations, we are not seeing a problem, at least not one 
being reported.
On the Linux implementation, the end user will occasionally get immediately 
kicked out with an invalid session immediately after providing credentials. The 
access logs show a single jsessionid=xxx being provided on the POST URL.  
Amazingly, sometimes that goes through and lets the user login, so my theory is 
that the browser is sometimes picking the wrong path.  (Also, theory, the "/" 
cookie is being generated by a request for "/favicon.ico" just before the 
request for the login page.)

So my question is:  Is there anything I can do from a configuration perspective 
to get it to NOT send the "/" cookie for APP2?

Deployment details:
Linux is being fronted by an HaProxy server, but the traffic appears to be 
staying on one host.
Server.xml is essentially the basic one provided with install.  Port # and 
access log information is modified and has RemoteIpValve setup so we can log 
the end user's IP.
Apps are deployed as war files with static context.xml files in 
Catalina/localhost.  Those files all look like:

  
  

War files do get exploded.  I can't find anything in the web.xml files that 
have anything to do with cookies.

Any help here would be appreciated.

Jeffrey Janner

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Friday, September 04, 2015 12:46 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: Multiple JSESSIONID cookies being presented.
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Jeffrey,
> 
> On 9/4/15 12:37 PM, Jeffrey Janner wrote:
> > I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but I'm
> > also seeing this on Windows (version doesn't matter), with Tomcat
> > 7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java 7U51.
> >
> > I have 2 contexts installed in Tomcat, one is ROOT, the other
> > APP2. Both contexts start off at a login screen unique to the
> > context and provided by it (not using container auth).
> >
> > When I connect to ROOT, no problem, but when I connect to APP2, I
> > get 2 JSESSIONID cookies, one with the path "/" and the other with
> > the path "/APP2/".
> 
> I would expect this behavior: you have one ROOT app (cookie path=/)
> and one APP2 app (cookie path=/APP2). Your browser will send both
> cookies to /APP2 because / is a prefix of /APP2.
> 
> > On the Windows implementations, we are not seeing a problem, at
> > least not one being reported.
> >
> > On the Linux implementation, the end user will occasionally get
> > immediately kicked out with an invalid session immediately after
> > providing credentials. The access logs show a single
> > jsessionid=xxx being provided on the POST URL.
> 
> The POST to j_security_check?
> 
No

> Are you using request.encodeURL() to build the  action URL, or
> are you building it manually?
> 
EncodeUrl.  And a check of a couple of sites, both linux and windows, shows 
that the jsessionid is being added to the action by EncodeUrl, regardless of 
cookie settings. So far, it is always the APP2 sessionID.

> I believe Tomcat prefers the Cookie-based session id to anything
> coming-in from the URL, and I do know it will search all JSESSIONID
> cookies for any that match a valid session (not just the first one) in
> the current application. So logging-in should ... always work.
> 
> > Amazingly, sometimes that goes through and lets the user login, so
> > my theory is that the browser is sometimes picking the wrong path.
> > (Also, theory, the "/" cookie is being generated by a request for
> > "/favicon.ico" just before the request for the login page.)
> 
> You should make sure that anything that doesn't require authentication
> specifically mentions that in web.xml, otherwise you'll get weird
> things happening like that.
> 
We don't actually use Tomcat container authentication at all.

> > So my question is:  Is there anything I can do from a
> > configuration perspective to get it to NOT send the "/" cookie for
> > APP2?
> 
> Not really... other than changing from ROOT to APP1 or whatever.
> Overlapping URL spaces for applications leads to tears.
> 
I could do that, though we'd like to keep it so that if no context is specified 
we still go to APP1, so the user's don't have to change all of their bookmarks. 
 Perhaps with a redirect?

> > Deployment details:
> 
> I think there's nothing in here that would change anything.
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> 
> iQIcBAEBCAAGBQJV6di6AAoJEBzwKT+lPKRY77QQAKzjMEDTVHYzqeFfhS9F9XUO
> qrIwlcXlxolclLO2CYaBNoYgcPm1CM8UPMc88s3ysmjLU37dohR8rd1Ukkyp9hdG
> 0hRV7siKip3t2sj/EDBmslJOKyShlURAqLne14MkQaVvYz/i985MUDrRnlx9zujf
> VjR5T0SV+M20ZOXoMN8S1ME09GMJktRajSs5T8rllwvMg+YtdmTo+hWfuerJNrj0
> yRBVFkAVs1UOH64RvHud+M3lYleb2UrrE/ZxofDihBcmipKWNEV6W/fu/7uEQVLc
> Hysc6CDh90L7xmoV8ndR6QoqNr4gX04mghRaU+PZiB6uPuPgYpJDaJ1wDITOrFnf
> BVkXYRh1KICMzSyW1T2K8ZU+NkG4dp0RVI++IzjOuDy+i/EJ9opnNyRols8NkC0w
> QLOueV6EbWZFbo9tZxJmaRS7Y7RObcbg/uk5JE9trK4KGcB/MtJQXWhk4Su5ZokS
> 5+knrgBbWbPcgH5x/1ten/BGkndp28C85FDci0AgsAFCbmim7KuuSL1oRRtLM5kw
> WNOeWpJzOQ3FAHV6TqPWLiAclo9/1gTMJZKQtxH+sW5OWYEa/9Ch2ZCArewy5Z+m
> KaNMfnXBrXlL9MGYyIQKiFVRUCyn/cyKKAlj9nLVbIBIsHeslCE7zq8zE15EOHVn
> 7v5mbzif9Ira1ZGLFBjC
> =5N0l
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Friday, September 04, 2015 2:55 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: Multiple JSESSIONID cookies being presented.
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Jeffrey,
> 
> On 9/4/15 3:31 PM, Jeffrey Janner wrote:
> >> -Original Message- From: Christopher Schultz
> >> [mailto:ch...@christopherschultz.net] Sent: Friday, September 04,
> >> 2015 12:46 PM To: Tomcat Users List <users@tomcat.apache.org>
> >> Subject: Re: Multiple JSESSIONID cookies being presented.
> >>
> > Jeffrey,
> >
> > On 9/4/15 12:37 PM, Jeffrey Janner wrote:
> >>>> I'm running Tomcat 8.0.24 on Ubuntu 14.04 with Java 8u45, but
> >>>> I'm also seeing this on Windows (version doesn't matter),
> >>>> with Tomcat 7.0.57 and Java 7u71, and Tomcat 6.0.43 and Java
> >>>> 7U51.
> >>>>
> >>>> I have 2 contexts installed in Tomcat, one is ROOT, the
> >>>> other APP2. Both contexts start off at a login screen unique
> >>>> to the context and provided by it (not using container
> >>>> auth).
> >>>>
> >>>> When I connect to ROOT, no problem, but when I connect to
> >>>> APP2, I get 2 JSESSIONID cookies, one with the path "/" and
> >>>> the other with the path "/APP2/".
> >
> > I would expect this behavior: you have one ROOT app (cookie
> > path=/) and one APP2 app (cookie path=/APP2). Your browser will
> > send both cookies to /APP2 because / is a prefix of /APP2.
> >
> >>>> On the Windows implementations, we are not seeing a problem,
> >>>> at least not one being reported.
> >>>>
> >>>> On the Linux implementation, the end user will occasionally
> >>>> get immediately kicked out with an invalid session
> >>>> immediately after providing credentials. The access logs show
> >>>> a single jsessionid=xxx being provided on the POST URL.
> >
> > The POST to j_security_check?
> >
> >> No
> 
> So... where does the POST go?
Direct to back-end processing in the app (as far as I know).

> 
> > Are you using request.encodeURL() to build the  action URL,
> > or are you building it manually?
> >
> >> EncodeUrl.  And a check of a couple of sites, both linux and
> >> windows, shows that the jsessionid is being added to the action
> >> by EncodeUrl, regardless of cookie settings. So far, it is always
> >> the APP2 sessionID.
> 
> I'm not surprised that the session id is being added to the URL
> regardless of cookie settings, because at that point, Tomcat might not
> know for sure if the client can support cookies. (I'm sure there are
> cases where it's obvious that cookies are in fact supported, but
> Tomcat is not detecting it.)
> 
That actually makes sense. 

> I'm surprised that Tomcat would use the "wrong" session id for
> URL-rewriting when presenting the login screen. Are you saying that,
> when showing the login page for /APP2, Tomcat will:
> 
> a. Place a session identifier in the URL with value X
> b. Return a Set-Cookie response header for JSESSIONID with value Y
> 
> Where X != Y?
So far, it looks like it is maintaining an X=Y philosophy.
So that's a non-starter.

> 
> > I believe Tomcat prefers the Cookie-based session id to anything
> > coming-in from the URL, and I do know it will search all
> > JSESSIONID cookies for any that match a valid session (not just the
> > first one) in the current application. So logging-in should ...
> > always work.
> >
> >>>> Amazingly, sometimes that goes through and lets the user
> >>>> login, so my theory is that the browser is sometimes picking
> >>>> the wrong path. (Also, theory, the "/" cookie is being
> >>>> generated by a request for "/favicon.ico" just before the
> >>>> request for the login page.)
> >
> > You should make sure that anything that doesn't require
> > authentication specifically mentions that in web.xml, otherwise
> > you'll get weird things happening like that.
> >
> >> We don't actually use Tomcat container authentication at all.
> 
> Okay, that's good information to have. But you do use Tomcat's
> session-tracking mechanisms, right?
> 
Yes, and the problem only rears its ugly head on a successful login (app 
expires old cookie, creates a new one).
User n

RE: Tomcat hanged on window server 2012

[Jeffrey Janner]

 -Original Message-
 From: dku...@ccilindia.co.in [mailto:dku...@ccilindia.co.in]
 Sent: Thursday, August 20, 2015 7:46 AM
 To: Tomcat Users List users@tomcat.apache.org
 Subject: Re: Tomcat hanged on window server 2012
 
 From:   Christopher Schultz ch...@christopherschultz.net
 To: Tomcat Users List users@tomcat.apache.org
 Date:   17-08-2015 18:32
 Subject:Re: Tomcat hanged  on window server 2012
 
 
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Dear Chris,
 
 Thanks for the reply, our response to ur questions are highlighted in
 blue.
 
 Any help is greatly appreciated.
 
 
 On 8/17/15 7:13 AM, dku...@ccilindia.co.in wrote:
  Our application worked fine on tomcat 8.0.22 on windows server 2003
   server. The tomcat server is restarted daily using a scheduler on
   shutdown.bat (at night) and startup.bat files (in the morning).
 
 I'm curious, why do you take-down your service overnight?
 
 1.We have downtime for our website.
 
  We have now upgraded our machine to windows server 2012 64 bit and
  now facing some serious issues like the tomcat remains in hanged
  stage( not responding state.).Once we restart the tomcat server,
  everything works fine.And this happens only once in a day. After
  the restart of tomcat,(manually by double click on shutdown.bat
  file and startup.bat file)  it never repeats.
 
 When you manually run shutown.bat/startup.bat, what is the effective
 user? When the scheduler runs, what is the effective user? Perhaps the
 environment is not configured correctly for one or the other of those.
 
 2. Manually clicking on the shutdown.bat file and letting it happen
 through a scheduler is done by the same user credentials.
 
Even though both methods may be using the same user-credentials, they are not 
run in the same environment. The task scheduler does not create a full user 
environment before launching the script. So there could still be some 
differences?

Q: why not implement it as a proper Windows service, using the native Commons 
Daemon wrapper which Apache readily provides?  Then you can use Windows net 
service stop/start commands to do the same thing?  If it still won't stop, you 
will need to check your code to see what thread(s) is not shutting down.

 
  We have not found any error in all the relevant log files.
 
  We have made the below changes while migration. 1. java upgrade
  from 1.7.0_40 to 1.8.0_25 2.Removed the tomcat-native.dll file from
  the bin folder.
 
 Why did you remove tomcat-native.dll? You could use the 64-bit version
 instead of the 32-bit version if you'd like.
 
 3. We have removed tomcat-native.dll file , because we were getting 
 org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR
 based Apache Tomcat Native library 1.1.32 using APR version 1.5.1.
 which
 was indicated as vullnerability by our security team. Also we are using
 NIO connector and not APR.
 
 
  The configuration of new windows server 2012 is as follows: OS
  Name:   Windows Server 2012-64 bit OS Version:
  6.2 java   1.8.0_25 (32 bit)
 

I recommend going ahead and getting the full 64-bit versions of java and tomcat.
Having all moving parts at the same bitness can save some head-scratching.

  However, we have observed the below error in the windows event
  viewer log
 
  A fatal alert was generated and sent to the remote endpoint. This
  may result in termination of the connection. The TLS protocol
  defined fatal error code is 10. The Windows SChannel error state is
  10.
 
 Check
 https://msdn.microsoft.com/en-us/library/windows/desktop/dd721886%28v=vs
 .85%29.aspx
 
 Error 10 is unexpected message, which might happen if your client
 was trying to connect using SSLv3 or some other unsupported protocol.
 What does your Connector look like?
 
 4. Our connector tag is as shown below.
 Connector protocol
 =org.apache.coyote.http11.Http11NioProtocol
 port=XXX maxHttpHeaderSize=8192 maxThreads=150
 minSpareThreads=25
 enableLookups=false
 disableUploadTimeout=true acceptCount=100 scheme=https
 secure=true
 clientAuth=false sslProtocol=TLS
 sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1 SSLEnabled=true
 allowUnsafeLegacyRenegotiation=false
 ciphers=XXX
 keystoreFile=X  keystorePass= server= 
 /Connector
 
  Is this error responsible for the hanging of tomcat server or Is it
  due to absence of tomcat-native.dll file ??? or is there any other
  reason why the tomcat server goes into hanging state ???
 
 A thread dump or two would be helpful:
 http://wiki.apache.org/tomcat/HowTo#If_you_are_running_on_Microsoft_Wind
 ows
 
 What you say that Tomcat has hung what do you mean? Will it respond
 to HTTP requests? If you run shutdown.bat, will it shutdown cleanly,
 or do you have to kill the process?
 
 5. Tomcat has hung means,the web page was not available and not
 responding for the end 

RE: Settings when SSL terminates on the front-end

[Jeffrey Janner]

 -Original Message-
 From: Mark Thomas [mailto:ma...@apache.org]
 Sent: Tuesday, June 23, 2015 3:18 PM
 To: Tomcat Users List
 Subject: Re: Settings when SSL terminates on the front-end
 
 On 17/06/2015 19:08, Jeffrey Janner wrote:
  I've been deploying letting Tomcat do it all when it came to
 connectors
  and SSL, with the app forcing everything to SSL in the
  security-constraints section.  Now I'm setting up a haproxy front-
 end
  that will both terminate the SSL and take care of the redirect from
 HTTP
  to HTTPS for me and tomcat only running a standard HTTP port on 8080.
 
  So my question is, Is it still important for the app to know that it
  operating secure, and if so, what settings are a must?
 
 Yes it is extremely important.
 
 You need secure=true for everything received over HTTPS and
 secure=false for everything received over HTTP.
 
 It is simpler in your case since Tomcat only ever sees traffic that has
 been received over HTTPS.
 
 There are several ways to ensure secure=true
 
 In your case, setting on the connector is the simplest and best option.
 
 If proxying over AJP, the AJP connector takes care of it.
 
 The RemoteIP[Valve|Filter] or the SSLValve can handle this if proxying
 over HTTP.
 
 
 There are several reasons it is important (the first reason is the big
 one):
 
 1. cookies created over secure connections will have the secure flag set
 which will ensure that browsers never send the cookie over HTTP. I once
 watched a customer go very white while I was explaining this when they
 realised that their banking app was sending authentication cookies over
 HTTP connections.
 
 2. The user data constraint in web.xml will only be satisfied if
 secure=true
 
 HTH,
 
 Mark

Thanks for the confirmation Mark. That is what I thought I'd gleaned from 
previous posts.  I will be sure to mark the http connection secure=true in my 
Tomcat instances.
I gather from #2 above, that having the secure setting on the http port, it 
won't really matter if the security-constraints exists in the web.xml or not, 
because Tomcat will assume it is already secure.  Ergo, I don't have to get the 
developers to remove it. 
That is fine with me. 
Thanks again.
Jeff

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

RE: Settings when SSL terminates on the front-end

[Jeffrey Janner]

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Thursday, June 18, 2015 8:59 AM
 To: Tomcat Users List
 Subject: Re: Settings when SSL terminates on the front-end
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Jeffrey,
 
 On 6/17/15 2:08 PM, Jeffrey Janner wrote:
  I’ve been deploying letting Tomcat do it all when it came to
  connectors and SSL, with the app forcing everything to SSL in the
  security-constraints section.  Now I’m setting up a haproxy
  front-end that will both terminate the SSL and take care of the
  redirect from HTTP to HTTPS for me and tomcat only running a
  standard HTTP port on 8080.
 
  So my question is, Is it still important for the app to know that
  it operating “secure”, and if so, what settings are a must?
 
 I would say that Tomcat knowing that it's in secure mode is
 important. If for no other reason than the URLs your webapp generates
 ought to be sensitive to the protocol being used.
 
  Here is the old setup:
 
  SERVER.XML:
 
  Service name=Catalina
 
  Connector address=${IP_ADDRESS} port=80
  maxHttpHeaderSize=8192
 
  maxThreads=50 enableLookups=false redirectPort=443
  acceptCount=100
 
  connectionTimeout=2 disableUploadTimeout=true
  compression=on
 
 
  compressableMimeType=text/html,text/xml,text/plain,text/css,text/csv,
 text/javascript,text/rtf,text/richtext
 
   /
 
  Connector address=${IP_ADDRESS} port=443
  maxHttpHeaderSize=8192
 
  maxThreads=150 enableLookups=false acceptCount=100
 
  connectionTimeout=2 disableUploadTimeout=true
  compression=on
 
 
  compressableMimeType=text/html,text/xml,text/plain,text/css,text/csv,
 text/javascript,text/rtf,text/richtext
 
   scheme=https secure=true SSLEnabled=true
 
 If you are still going to connect haproxy - Tomcat using port 443,
 then this configuration should still work. Tomcat will be in secure
 mode, but you won't have access to the original SSL information, at
 least not directly in the usual ways.
 
  Here is the new setup:
 
  SERVER.XML:
 
  Service name=Catalina
 
  Connector port=${tomcatPort} protocol=HTTP/1.1
 
  connectionTimeout=2
 
  redirectPort=8443 /
 
 You should probably set protocol=https and secure=true. You don't
 need redirectPort if this is the connector that handles incoming
 connections from haproxy.
 

Thanks for the commentary Chris.
Just one thing, the proxy -- tomcat connection is expected to be http (8080), 
not https.
From paying attention over the years, I think I'm supposed to set secure=true 
on the one and only http connector in the current setup.
That is what I am looking for verification.
Jeff

Settings when SSL terminates on the front-end

[Jeffrey Janner]

I've been deploying letting Tomcat do it all when it came to connectors and 
SSL, with the app forcing everything to SSL in the security-constraints 
section.  Now I'm setting up a haproxy front-end that will both terminate the 
SSL and take care of the redirect from HTTP to HTTPS for me and tomcat only 
running a standard HTTP port on 8080.
So my question is, Is it still important for the app to know that it operating 
secure, and if so, what settings are a must?
Here is the old setup:

SERVER.XML:
Service name=Catalina
Connector address=${IP_ADDRESS} port=80 maxHttpHeaderSize=8192
   maxThreads=50 enableLookups=false redirectPort=443 
acceptCount=100
   connectionTimeout=2 disableUploadTimeout=true 
compression=on
   
compressableMimeType=text/html,text/xml,text/plain,text/css,text/csv,text/javascript,text/rtf,text/richtext
/
Connector address=${IP_ADDRESS} port=443 maxHttpHeaderSize=8192
   maxThreads=150 enableLookups=false acceptCount=100
   connectionTimeout=2 disableUploadTimeout=true 
compression=on
   
compressableMimeType=text/html,text/xml,text/plain,text/css,text/csv,text/javascript,text/rtf,text/richtext
   scheme=https secure=true SSLEnabled=true
   SSLHonorCipherOrder=true
   SSLCipherSuite=list-of-ciphers
   SSLCertificateFile=path-to-server.crt
   SSLCertificateKeyFile=path-to-server.key
   SSLCertificateChainFile=path-to-server_chain.crt
   SSLPassword=password /
Engine name=Catalina defaultHost=localhost 
  Host name=localhost  appBase= webapps
   unpackWARs=true autoDeploy=false deployXML = false
Valve className=org.apache.catalina.valves.AccessLogValve 
directory=logs
   prefix=localhost_access_log. suffix=.txt
   pattern=%h %l %u %t quot;%rquot; %s %b /
  /Host
/Engine
  /Service

CONTEXT.XML:  No tomcat-level parameters specified

WEB.XML: (only the important bits, assume servlets and filters won't change)
security-constraint
web-resource-collection
web-resource-nameEverything/web-resource-name
url-pattern/*/url-pattern
/web-resource-collection
user-data-constraint
transport-guaranteeCONFIDENTIAL/transport-guarantee
/user-data-constraint
/security-constraint

Here is the new setup:
SERVER.XML:
Service name=Catalina
Connector port=${tomcatPort} protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 /
   Engine name=Catalina defaultHost=localhost  jvmRoute=serverX
  Host name=localhost  appBase= webapps
   unpackWARs=true autoDeploy=false deployXML = false
Valve className=org.apache.catalina.valves.AccessLogValve 
directory=logs
   prefix=localhost_access_log. suffix=.txt
   pattern=%h %l %u %t quot;%rquot; %s %b /
  /Host
/Engine
  /Service

CONTEXT.XML: no changes
WEB.XML: drop the security-constraints section?

Am I missing something from a security standpoint here?
And yes, I'm aware I need to adjust some parameters in the Connector that are 
left out in the second example.  I'm just interested in things like 
secure-cookie, etc.


Jeffrey Janner
Sr. Network Administrator
jeffrey.jan...@polydyne.commailto:first.l...@polydyne.com
PolyDyne Software Inc.
Main:   512.343.9100
Direct:  512.583.8930

 [cid:image002.png@01CC0FB7.4FF43CE0]

Speed, Intelligence  Savings in Sourcing

RE: Shutdown port and multiple Tomcat instances

[Jeffrey Janner]

Left out the important bits:
Tomcat 7.x - latest release
Ubuntu 14.04 - though could be any Linux
Java 1.7.0_80

Upgrade to Tomcat 8.x

From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
Sent: Monday, June 15, 2015 9:49 AM
To: 'Tomcat Users List'
Subject: Shutdown port and multiple Tomcat instances

I'm making the switch to running all my tomcats on Linux.
I'm planning to deploy multiple instances per machine, splitting catalina_base 
and catalina_home, and just have question on the shutdown port.
Under Windows, I just deployed the binary with the commons daemon wrapper and 
set the shutdown port to -1 and let the daemon manage the orderly shutdown.
Is it possible to set the port to -1 under Linux and do something similar? 
Preferably without deploying the daemon wrapper also, though I'm willing to do 
if necessary.  I am planning to manage them with service/init scripts for 
startup and shutdown.


Jeffrey Janner
Sr. Network Administrator
jeffrey.jan...@polydyne.commailto:first.l...@polydyne.com
PolyDyne Software Inc.
Main:   512.343.9100
Direct:  512.583.8930

 [cid:image002.png@01CC0FB7.4FF43CE0]

Speed, Intelligence  Savings in Sourcing

Shutdown port and multiple Tomcat instances

[Jeffrey Janner]

I'm making the switch to running all my tomcats on Linux.
I'm planning to deploy multiple instances per machine, splitting catalina_base 
and catalina_home, and just have question on the shutdown port.
Under Windows, I just deployed the binary with the commons daemon wrapper and 
set the shutdown port to -1 and let the daemon manage the orderly shutdown.
Is it possible to set the port to -1 under Linux and do something similar? 
Preferably without deploying the daemon wrapper also, though I'm willing to do 
if necessary.  I am planning to manage them with service/init scripts for 
startup and shutdown.


Jeffrey Janner
Sr. Network Administrator
jeffrey.jan...@polydyne.commailto:first.l...@polydyne.com
PolyDyne Software Inc.
Main:   512.343.9100
Direct:  512.583.8930

 [cid:image002.png@01CC0FB7.4FF43CE0]

Speed, Intelligence  Savings in Sourcing

RE: Shutdown port and multiple Tomcat instances

[Jeffrey Janner]

 -Original Message-
 From: Mark Thomas [mailto:ma...@apache.org]
 Sent: Monday, June 15, 2015 9:51 AM
 To: Tomcat Users List
 Subject: Re: Shutdown port and multiple Tomcat instances
 
 On 15/06/2015 15:49, Jeffrey Janner wrote:
  I'm making the switch to running all my tomcats on Linux.
 
  I'm planning to deploy multiple instances per machine, splitting
  catalina_base and catalina_home, and just have question on the
 shutdown
  port.
 
  Under Windows, I just deployed the binary with the commons daemon
  wrapper and set the shutdown port to -1 and let the daemon manage the
  orderly shutdown.
 
  Is it possible to set the port to -1 under Linux and do something
  similar? Preferably without deploying the daemon wrapper also, though
  I'm willing to do if necessary.  I am planning to manage them with
  service/init scripts for startup and shutdown.
 
 Yes, kill -15 pid will trigger a clean shutdown.
 
 Mark
 
Thanks Mark.
Trying to keep the deployment as clean as possible for the moment.
I'll look some more into the benefits of running Tomcat under the commons 
daemon at a future date.
As it is, I'm probably going to need to deploy it for a couple of related 
standalone java apps.
Jeff


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

RE: Shutdown port and multiple Tomcat instances

[Jeffrey Janner]

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Monday, June 15, 2015 10:02 AM
 To: Tomcat Users List
 Subject: Re: Shutdown port and multiple Tomcat instances
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Jeffrey,
 
 On 6/15/15 10:49 AM, Jeffrey Janner wrote:
  I’m making the switch to running all my tomcats on Linux.
 
  I’m planning to deploy multiple instances per machine, splitting
  catalina_base and catalina_home, and just have question on the
  shutdown port.
 
  Under Windows, I just deployed the binary with the commons daemon
  wrapper and set the shutdown port to -1 and let the daemon manage
  the orderly shutdown.
 
  Is it possible to set the port to -1 under Linux and do something
  similar? Preferably without deploying the daemon wrapper also,
  though I’m willing to do if necessary.  I am planning to manage
  them with service/init scripts for startup and shutdown.
 
 The *NIX analog to the Windows Service runner /is/ jsvc.
 
 I'm curious why you don't want to run jsvc.
 
 If you don't want to run jsvc, why not pick a unique shutdown port
 number and use the standard scripts?
 
 We run multiple JVMs on a single machine, and we even (in dev) have
 multiple users with multiple JVMs, etc. *and* we are using mod_jk to
 connect them all, so we have to manage ports carefully.
 
 We have come up with this method to organize everything:
 
 1. Each user has a user number -- let's call that u
 2. Each application has an app number -- let's call that a
 
 Port numbers now look like this:
 
 8ua5 - ajp port for the application
 8ua6 - shutdown port for the application
 8ua7 - secure port for loopback requests from other apps
(if necessary for the application)
 
 We have scripts that use these things so a user just has to set up
 their u and a values properly and everything works. It's also
 possible to predict who will be using what port, and - ignoring typos
 - - nobody has any conflicts.
 
 - -chris

Thanks for the tips Chris.  That could really come in useful.
I'm not adverse to running jsvc, I'm just under a current time crunch and have 
something like 50 of these to turn out in short order.  I didn't want to have 
to mess with getting another layer to work right now.
Jeff

RE: Shutdown port and multiple Tomcat instances

[Jeffrey Janner]

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Monday, June 15, 2015 10:02 AM
 To: Tomcat Users List
 Subject: Re: Shutdown port and multiple Tomcat instances
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Jeffrey,
 
 On 6/15/15 10:49 AM, Jeffrey Janner wrote:
  I’m making the switch to running all my tomcats on Linux.
 
  I’m planning to deploy multiple instances per machine, splitting
  catalina_base and catalina_home, and just have question on the
  shutdown port.
 
  Under Windows, I just deployed the binary with the commons daemon
  wrapper and set the shutdown port to -1 and let the daemon manage
  the orderly shutdown.
 
  Is it possible to set the port to -1 under Linux and do something
  similar? Preferably without deploying the daemon wrapper also,
  though I’m willing to do if necessary.  I am planning to manage
  them with service/init scripts for startup and shutdown.
 
 The *NIX analog to the Windows Service runner /is/ jsvc.
 
 I'm curious why you don't want to run jsvc.
 
 If you don't want to run jsvc, why not pick a unique shutdown port
 number and use the standard scripts?
 
 We run multiple JVMs on a single machine, and we even (in dev) have
 multiple users with multiple JVMs, etc. *and* we are using mod_jk to
 connect them all, so we have to manage ports carefully.
 
 We have come up with this method to organize everything:
 
 1. Each user has a user number -- let's call that u
 2. Each application has an app number -- let's call that a
 
 Port numbers now look like this:
 
 8ua5 - ajp port for the application
 8ua6 - shutdown port for the application
 8ua7 - secure port for loopback requests from other apps
(if necessary for the application)
 
 We have scripts that use these things so a user just has to set up
 their u and a values properly and everything works. It's also
 possible to predict who will be using what port, and - ignoring typos
 - - nobody has any conflicts.
 
 - -chris
 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - http://gpgtools.org
 
 iQIcBAEBCAAGBQJVfuj7AAoJEBzwKT+lPKRYmSwQAKTsfdDArTB62NLzB8XjiQgy
 8KzChtOr/kcczKyVJ4Q1WVuraqb0Q5QX89HZT9W/LvQQ0t3RDseXf/cLmicPOkAJ
 iR6EFHugvf3RUCQq96uF4Z4Vm8YJkZyx1ZYPbBhE2yxbqKSguDqeuLApwEmlrIiB
 RWhccMg0l8v5Bn8iqlHvCJEZ0593JB3PPK5cCkNvRQi475VWXnWIGHOfQfJT7Me7
 e3bML4+v+mvkFdOsqGU8uRz8YjArDJlUrPYxs1uAMsc0XaURJ+IZCkKWBWL1Pkem
 9ht6L+57L/RdUkOtCT56cZ/LkehQHW8e8c8aEwv70ItBfd+1joV47BA/Jz8rkfi/
 8FWfNiXWwEPEZO/p1WEZETmF+38yhuerB3n5WIfpWWkm1M3K3CHq30J2Kvf7p0Br
 2N7RwvPL9ZGrA34av0sWnmhpwKqM1+7LttCep7mmPguFgye6CHd9V1hdKIoKaXyP
 mcc8gjukZ24kd/kN6wVCbqwEWtW0+ozcNVA2fF3pkAZB5CUNo4Ooqy+drgWMySUd
 RT0E6f3U7pyvNqAyEPMxMS5ktZKdEqyhVjacuq1eCj0dDmvhYnulQtnzMaBQQMm3
 t1wC0w4Mrd4QH085xJK7FOueOaV5TN0S/QzSJKkgDR8RRBIJZPo8BeTf7xQ3urr6
 RU3E6P54XhRW9ccpXhNl
 =GE4t
 -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: can we pass OS username while connection Database from Tomcat

[Jeffrey Janner]

I believe what you are asking for is already available.  See inline comments 
below.

 -Original Message-
 From: Vijay Kumar [mailto:vijy.gan...@gmail.com]
 Sent: Monday, June 01, 2015 7:48 AM
 To: Tomcat Users List
 Subject: Re: can we pass OS username while connection Database from
 Tomcat
 
 Hi,
 
 Client want to monitor whether the connection is established from my
 application or their existing applications. Because all these are
 connecting the database from APPS user.
 
 1) My Tomcat is installed on a different Linux environment under a user,
 so
 if i could at least pass this user then Client can able to identify that
 the connection is established from my Application.
 
 2) By querying the v$session table in Oracle we can get all the
 connection
 information but we can't identify the connections that are created from
 my
 application because all the applications are connecting database through
 APPS user.
 

V$SESSION already contains the columns MACHINE and OSUSER and these values 
should be populated by the Oracle driver.  They are on all my systems.  Should 
be everything you need to meet your requirement, unless you are running on the 
same box and same O/S user as your client's legacy programs.


 We can achieve this by creating a new schema and providing all the
 required
 permissions to my schema and accessing the database from the created
 schema
 but is there any option where we can achieve my requirement.
 I found that by providing a attribute called 'connectionProperties' in
 Resource Tag of the context.xml is achieved this. But am not seeing any
 information about the Program name after connecting to database.
 Eg :
 connectionProperties=v$session.program=dev-cs
 
This is the V$SESSION column PROGRAM, which the Oracle Thin Client does not set 
automatically.  The Thick client (OCI drivers) will set it for you. I think you 
can modify your code to set it when creating the connection, but I'm not sure 
how.

For this use case, Google is your friend.  Or ask on an Oracle/Java forum.

 
 Thanks,
 Vijay G
 
 On Fri, May 29, 2015 at 8:48 PM, Jeffrey Janner
 jeffrey.jan...@polydyne.com
  wrote:
 
  Please see response below post:
 
   -Original Message-
   From: Vijay Kumar [mailto:vijy.gan...@gmail.com]
   Sent: Thursday, May 28, 2015 7:22 AM
   To: Tomcat Users List
   Subject: Re: can we pass OS username while connection Database from
   Tomcat
  
   Hi ,
  
   I am referring User_Id as Linux User_id where we installed Tomcat.
  
   My Oracle Database don't know about this user_id.
  
  
   Thanks,
   Vijay G
  
  Vijay -
  As another tomcat-oracle integrator, I do have to ask, exactly what
 is it
  your client is trying to monitor and what tool is he going to use?
  But first let's clarify the question:
  1) Tomcat is running as the O/S user apps and your client
 wants
  to see the connections from O/S user apps?  And why?  This may already
 be
  available in the database structures.
  or
  2) Tomcat is connecting to the database using the schema name
  apps and the client want to see these connections?  That's already
  available on the Oracle side.  This depends on what tool the client is
  using.
  Or
  3) the client wants to see the user names of the application
 users
  in the monitoring tool?  Depending on this answer and the tool used,
 you
  are really getting into Oracle programming territory, as there are
 several
  ways to do this.
 
  As for answering the straight-forward question, a quick Google search
  found several replies, all requiring changes to the application code
 that
  connects to the database. Actually from what I understand, the Oracle
  drivers already provide this, at least the latest versions.
 
  Jeff
 
 
   On Thu, May 28, 2015 at 3:20 PM, André Warnier a...@ice-sa.com
 wrote:
  
Vijay Kumar wrote:
   
Hi Mark,
   
Please find below my exact requirement.
   
I have Oracle Database where my objects are installed and I have
 also
   a
Linux instance where i installed Tomcat.
I am currently creating connection to the Oracle database from
 Tomcat
using
'apps' user as this schema is having all permissions.
   
One of my client want to monitor the connections that are created
   from my
application. For this i want to pass my Linux user information
   (userid)
while creating the connection from my application or in
 context.xml
   file.
   
Please suggest the approaches? If SPENGO can you redirect me any
   doc/post
how to achieve this?
   
 Vijay,
you are repeating yourself (and still top-posting), but you are
 not
providing the crucial information which would enable someone to
 really
   help
you.
For example, what Linux user information (userid) are you
 talking
   about ?
   
Is it the Linux user-id under which Tomcat is running ?
That would probably be tomcat, so that is probably not going to
 help
   you
fulfill your customer's wishes

RE: can we pass OS username while connection Database from Tomcat

[Jeffrey Janner]

Please see response below post:

 -Original Message-
 From: Vijay Kumar [mailto:vijy.gan...@gmail.com]
 Sent: Thursday, May 28, 2015 7:22 AM
 To: Tomcat Users List
 Subject: Re: can we pass OS username while connection Database from
 Tomcat
 
 Hi ,
 
 I am referring User_Id as Linux User_id where we installed Tomcat.
 
 My Oracle Database don't know about this user_id.
 
 
 Thanks,
 Vijay G
 
Vijay -
As another tomcat-oracle integrator, I do have to ask, exactly what is it your 
client is trying to monitor and what tool is he going to use?
But first let's clarify the question:
1) Tomcat is running as the O/S user apps and your client wants to 
see the connections from O/S user apps?  And why?  This may already be 
available in the database structures.
or
2) Tomcat is connecting to the database using the schema name apps 
and the client want to see these connections?  That's already available on the 
Oracle side.  This depends on what tool the client is using.
Or
3) the client wants to see the user names of the application users in 
the monitoring tool?  Depending on this answer and the tool used, you are 
really getting into Oracle programming territory, as there are several ways to 
do this. 

As for answering the straight-forward question, a quick Google search found 
several replies, all requiring changes to the application code that connects to 
the database. Actually from what I understand, the Oracle drivers already 
provide this, at least the latest versions.

Jeff


 On Thu, May 28, 2015 at 3:20 PM, André Warnier a...@ice-sa.com wrote:
 
  Vijay Kumar wrote:
 
  Hi Mark,
 
  Please find below my exact requirement.
 
  I have Oracle Database where my objects are installed and I have also
 a
  Linux instance where i installed Tomcat.
  I am currently creating connection to the Oracle database from Tomcat
  using
  'apps' user as this schema is having all permissions.
 
  One of my client want to monitor the connections that are created
 from my
  application. For this i want to pass my Linux user information
 (userid)
  while creating the connection from my application or in context.xml
 file.
 
  Please suggest the approaches? If SPENGO can you redirect me any
 doc/post
  how to achieve this?
 
   Vijay,
  you are repeating yourself (and still top-posting), but you are not
  providing the crucial information which would enable someone to really
 help
  you.
  For example, what Linux user information (userid) are you talking
 about ?
 
  Is it the Linux user-id under which Tomcat is running ?
  That would probably be tomcat, so that is probably not going to help
 you
  fulfill your customer's wishes.
 
  Is it the user-id of the /user/ of your Tomcat application ?
  In that case, how does Tomcat know this user-id ? Do the users login
 into
  your application ? How ? What is the user authentication mechanism
 being
  used, now, at the Tomcat level ?
 
  Does the Oracle database also know this user-id ? How ?
 
  What does One of my client want to monitor the connections mean,
 exactly
  ? what does the customer want to know, and when ? Is this customer the
 only
  user/manager of the Oracle database, or are there multiple
 users/managers
  of the Oracle database ?
 
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 

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

RE: Problem specifying cipher suites in tomcat6

[Jeffrey Janner]

 -Original Message-
 From: Ramon Pfeiffer [mailto:ramon.pfeif...@uni-tuebingen.de]
 Sent: Friday, May 29, 2015 2:33 AM
 To: users@tomcat.apache.org
 Subject: Re: Problem specifying cipher suites in tomcat6
 
 Am 28.05.2015 um 18:56 schrieb Caldarale, Charles R:
  From: Ramon Pfeiffer [mailto:ramon.pfeif...@uni-tuebingen.de]
  Subject: Problem specifying cipher suites in tomcat6
 
  I'm currently trying to specify a list of cipher suites to be used by
 my
  connector in Tomcat 6.0.24.
 
  Anybody can shed some light on what I did wrong?
 
  Using a version of Tomcat that's more than five years old is the first
 thing - there have been many, many security fixes since then, including
 some related to the ciphers attribute.  You also need to tell us the JVM
 version, the platform you're running on, and whether or not APR is in
 use for this Connector (it's in the logs).
 
 Sadly, it's a system I inherited last year and now have the pleasure to
 work with. I can't update Tomcat for I don't know what will break.
 
 Anyway, I'm working on a RHEL6 system. A java -version yields
 # java -version
 java version 1.7.0_79
 OpenJDK Runtime Environment (rhel-2.5.5.3.el6_6-x86_64 u79-b14)
 OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)
 
 APR is not installed.
 
 Thanks,
 Ramon
You should be able to upgrade to the latest version of Tomcat 7 with little to 
no problem. 
Get the latest release from the tomcat website, not the Red Hat RPM and you can 
install it in parallel with your existing Tomcat, so you can switch back 
quickly if you do experience a problem related to the upgrade.
You will need to migrate your server.xml file and possibly you context.xml 
files as well, though unlikely in the latter case.
I know that a lot depends on how tightly integrated your app is with tomcat, 
but I made the migration with almost no difficulty years ago.
Jeff 

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

RE: native API - to make Apache/Tomcat faster

[Jeffrey Janner]

 -Original Message-
 From: Christoph P.U. Kukulies [mailto:k...@kukulies.org]
 Sent: Tuesday, May 26, 2015 9:37 AM
 To: Tomcat Users List
 Subject: Re: native API - to make Apache/Tomcat faster
 
 Am 26.05.2015 um 15:36 schrieb Christopher Schultz:
 
  So you are using either mod_proxy_ajp or mod_proxy?
 
 mod_proxy
 
 
 
  Are you using TLS anywhere in the mix? (I should hope so, since you
  are deploying a CMS). Does httpd terminate TLS? Do you encrypt the
  connection(s) between httpd and Tomcat using TLS?
 
 No, not using TSL between Apache and tomcat. Using secure http (https)
 is
 planned to be used soon.
 
  We are observing that the server sometimes delivers pages
  incompletely.
  Have you been able to determine if Tomcat is not sending the whole
  page, or if httpd is not proxying the whole page?
 
 I have not yet found the time to debug the connection and to locate the
 actual
 missing pieces. It just seems that some js or css is not being loaded
 since the source
 code of the page itself is there.
 
 
  Portions of the page do not show and trying to restart the service
  results in a time out.
  A time out where? The service-restart times out, or after a service
  restart, requests time out?
 
 When I type NET STOP tomcat7 on the server to stop the service, it
 hangs. Normally
 the service should be shut down smoothly.
 
From my experience, this is a symptom that indicates that the JVM has died but 
the service wrapper didn't catch it and is still running. Or perhaps just an 
important thread died in the JVM.  Check your Tomcat and application logs for 
errors (OOM errors particularly exhibit this symptom).

 
  I'm unaware of any problems when up-to-date versions of all components
  are being used.
 
  The rebooting the server is a cure.
  That seems to be a popular cure with Microsoft Windows servers ;)
 
 
 --
 Christoph
 
 
 -
 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: AJP config questions

[Jeffrey Janner]

Thanks for the guidance guys.  I understand it better.
See in-line comments:

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Friday, May 15, 2015 7:03 AM
 To: Tomcat Users List
 Subject: Re: AJP config questions
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Jeffrey,
 
 On 5/14/15 6:38 PM, Jeffrey Janner wrote:
  (Hopefully, this isn't a duplicate post, but I sent the original a
  half-hour ago and I haven't seen it come back yet.)
 
  Guys, it's been a long time since I did any work with AJP, but it
  looks like something I'll be implementing soon. I have a couple of
  basic questions, mostly related to ProxyPassReverse, but also one
  related to SSL.
 
  I know to turn on mod_proxy and mod_proxy_ajp and a simple
  ProxyPass where the source and dest paths match, i.e. both are
  /foo. The question is if they differ. The httpd docs give this
  example:
 
  Rewriting Proxied Path ProxyPass /apps/foo
  ajp://backend.example.com:8009/foo ProxyPassReverse /apps/foo
  http://www.example.com/foo
 
  but don't mention if you need to turn on the RewriteEngine. Also,
  the second line doesn't look correct. Shouldn't it be
  http://www.example.com/app/foo? Or maybe
  ajp://backend.example.com:8009/foo?
 
 Trying to re-name the context path during proxying is a road that ends
 in tears. ProxyPassReverse only re-writes headers like SetCookie and
 Location. If you have links within your pages, you'll need to use
 something like mod_html to re-write all of them as the page is
 streamed back to the client.
 
 Best practice is to re-name the application to apps#foo.war if that's
 really the URL path you want to use.
 
 (The above configuration does not use mod_rewrite, hence the absence
 of RewriteEngine On.)
 
  BTW: we don't seem to be able to get the example to work.
  ProxyPass /myapp ajp://localhost:8009/myapp  works, but
  ProxyPass /app ajp://localhost:8009/myapp does not work, and
  we've tried various iterations of ProxyPassReverse with it.
 
 When you say doesn't work, what do you really mean

Means we can't reach the app on the Tomcat side. 

 
  What's the best way to handle ROOT.war, assuming there are other
  webapps to deploy as well?
 
 This is tough. I would recommend that you put all web applications in
 distinct paths, and not use ROOT at all. It makes proxying a little
 more sane IMHO. You can definitely still do it (just do all your
 ProxyPasses for the non-ROOT webapps *first* in httpd.conf, and then
 have one that does something like ProxyPass / [endpoint] last to
 handle the ROOT webapp.
 
This will be very helpful, since the primary app is currently deployed as ROOT. 
(We are using Tomcat direct connections, but moving to an HTTPD front-end for a 
few deployments.)

 
  What if I don't want ROOT.war, but want to send / to a specific
  webapp?
 
 Put index.html into ROOT/index.html and do a redirect (or something
 roughly equivalent, like using RedirectMatch ^/$ /webapp/).
 
  SSL Question: Since our web.xml is configured to redirect all
  requests to SSL in the security-constraints area, how does that
  effect the options that need to be supplied in the connector? Right
  now, we just have the basic config as it comes in the initial
  conf.xml.
 
 When using mod_proxy_ajp, the SSL information should be passed-over
 from httpd to Tomcat just like when you are using mod_jk, so I don't
 think you'll get a redirect storm. mod_jk sends-over some extra stuff
 by default that mod_proxy_ajp I think does not, but I can't remember
 off the top of my head what those things are.
 
 
OK, I was just wondering what parameters need to be set in the Connector for 
AJP and if any needed to be specified for the whole redirect to SSL thingy. I'm 
guessing it still needs a redirect parameter in the above case?  Re-reading the 
documentation.

  Sorry for being a newbie on this, but the last time I messed with
  Apache proxy was 4.0 and then I used JK.
 
 You can still certainly use mod_jk, but you'll find the same issues
 with path-rewriting. I've been using mod_jk forever and I have no
 plans to abandon it. mod_jk is alive and well if you'd prefer to use
 something with which you have previous experience.
 
 But you do have to build it separately, since it doesn't come bundled
 with httpd (which is definitely a bummer).
 
 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2
 Comment: GPGTools - http://gpgtools.org
 
 iQIcBAEBCAAGBQJVVeBnAAoJEBzwKT+lPKRYsAwP/086jW4zeX/5BZxJyMsEbjLp
 fEJCj8tJguyKoXRkgVIqeVW9aHK86elY3JYaAx/00GmrZACZbk2J963XB58E3YyV
 C3bd3K1BkHGYsWCoYwqEcNUIygnaJEuWrydXalcJrvrsk5vprkkFKQE/yu2Wu7gg
 vdNcbLe+LwySbYAJdzrBWYiyTFqarA/ShFkyMcpsEz+TWpbcDZptfpLLs2M30lPz
 /53OaJvfVs4yle/nXaqvG7R61RXc1/JkEOVApXMhn+lCnP2XBwNhVtpqsAjwIRMv
 ArdZClXH5wEpB+8rwWZVwMVQhJZJqGZXjBX8k9r1zNoXzomN6TWnB6zcnjOBpMVC
 RaErv9KQmSDsRWwmz5wyhdHWNPOVo48g0oCZhg22cF4tCXd879x25P4HIEyR5hT/
 oJppa8kT7nSSaRQbq3s0n1LrBUMa7FqF+544zID6HnATSlNVADP5DOMUFrrEU+yH

AJP config questions

[Jeffrey Janner]

(Hopefully, this isn't a duplicate post, but I sent the original a half-hour 
ago and I haven't seen it come back yet.)

Guys, it's been a long time since I did any work with AJP, but it looks like 
something I'll be implementing soon.
I have a couple of basic questions, mostly related to ProxyPassReverse, but 
also one related to SSL.

I know to turn on mod_proxy and mod_proxy_ajp and  a simple ProxyPass where the 
source and dest paths match, i.e. both are /foo.  The question is if they 
differ.  The httpd docs give this example:

   Rewriting Proxied Path
   ProxyPass /apps/foo ajp://backend.example.com:8009/foo
   ProxyPassReverse /apps/foo http://www.example.com/foo

but don't mention if you need to turn on the RewriteEngine.
Also, the second line doesn't look correct.  Shouldn't it be 
http://www.example.com/app/foo?
Or maybe ajp://backend.example.com:8009/foo?

BTW: we don't seem to be able to get the example to work.
ProxyPass /myapp ajp://localhost:8009/myapp  works, but
ProxyPass /app ajp://localhost:8009/myapp does not work, and we've tried 
various iterations of ProxyPassReverse with it.

What's the best way to handle ROOT.war, assuming there are other webapps to 
deploy as well?
What if I don't want ROOT.war, but want to send / to a specific webapp?

SSL Question:
Since our web.xml is configured to redirect all requests to SSL in the 
security-constraints area, how does that effect the options that need to be 
supplied in the connector?  Right now, we just have the basic config as it 
comes in the initial conf.xml.

Sorry for being a newbie on this, but the last time I messed with Apache proxy 
was 4.0 and then I used JK.

Jeffrey Janner

AJP config questions

[Jeffrey Janner]

Guys, it's been a long time since I did any work with AJP, but it looks like 
something I'll be implementing soon.
I have a couple of basic questions, mostly related to ProxyPassReverse, but 
also one related to SSL.

I know to turn on mod_proxy and mod_proxy_ajp and  a simple ProxyPass where the 
source and dest paths match, i.e. both are /foo.  The question is if they 
differ.  The httpd docs give this example:

Rewriting Proxied Path
ProxyPass /apps/foo ajp://backend.example.com:8009/foo
ProxyPassReverse /apps/foo http://www.example.com/foo

but don't mention if you need to turn on the RewriteEngine.
Also, the second line doesn't look correct.  Shouldn't it be 
http://www.example.com/app/foo?
BTW: we don't seem to be able to get that to work.
ProxyPass /myapp ajp://localhost:8009/myapp  works, but
ProxyPass /app ajp://localhost:8009/myapp does not work, and we've tried 
various iterations of ProxyPassReverse with it.

What's the best way to handle ROOT.war, assuming there are other webapps to 
deploy as well?
What if I don't want ROOT.war, but want to send / to a specific webapp?

SSL Question:
Since our web.xml is configured to redirect all requests to SSL in the 
security-constraints area, how does that effect the options that need to be 
supplied in the connector?  Right now, we just have the basic config as it 
comes in the initial conf.xml.

Sorry for being a newbie on this, but the last time I messed with Apache proxy 
was 4.0 and then I used JK.

Jeffrey Janner

RE: Tomcat 7.0.57 - Deployment Issue

[Jeffrey Janner]

 -Original Message-
 From: Kiran Badi [mailto:ki...@poonam.org]
 Sent: Tuesday, May 12, 2015 9:30 PM
 To: Tomcat Users List
 Subject: Re: Tomcat 7.0.57 - Deployment Issue
 
 Thanks Hassan/Prabhu/Charles for reply.
 
 I tried the options given in this link.
 
 http://wiki.apache.org/tomcat/TomcatDevelopmentVirtualHosts
 
 but for some reasons still its not working.I have pasted the server xml
 for
 reference. I have unlimited website hosting plan with arvixe.com , but
 for
 some reasons it's still not working.Not sure if these guys needs to add
 something special to hosts file.
 
 here is link for actual site -
 
 homelyhotels.com - you will probably see cgi-bin folder.
 
 Below server xml, I have added just a second host tag for webapp2. I am
 bit
 hesitant to make changes wrt to webapp1(removing context tags etc due to
 lack of time on my end along with lack of sufficient knowledge in case
 something breaks,however I will eventually clean that as well).
 
...
 !-- An Engine represents the entry point (within Catalina) that
 processes
  every request.  The Engine implementation for Tomcat stand
 alone
  analyzes the HTTP headers included with the request, and passes
 them
  on to the appropriate Host (virtual host).
  Documentation at /docs/config/engine.html --
 
 !-- You should set jvmRoute to support load-balancing via AJP ie :
 Engine name=Catalina defaultHost=localhost jvmRoute=jvm1
 --
 Engine name=Catalina defaultHost=localhost
 
   !--For clustering, please take a look at documentation at:
   /docs/cluster-howto.html  (simple how to)
   /docs/config/cluster.html (reference documentation) --
   !--
   Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster/
   --
 
   !-- Use the LockOutRealm to prevent attempts to guess user
 passwords
via a brute-force attack --
   Realm className=org.apache.catalina.realm.LockOutRealm
 !-- This Realm uses the UserDatabase configured in the global
 JNDI
  resources under the key UserDatabase.  Any edits
  that are performed against this UserDatabase are
 immediately
  available for use by the Realm.  --
 Realm className=org.apache.catalina.realm.UserDatabaseRealm
resourceName=UserDatabase/
   /Realm
 
   Host name=localhost  appBase=webapps
 unpackWARs=true autoDeploy=true
 
 !-- SingleSignOn valve, share authentication between web
 applications
  Documentation at: /docs/config/valve.html --
 !--
 Valve
 className=org.apache.catalina.authenticator.SingleSignOn /
 --
 
 !-- Access log processes all example.
  Documentation at: /docs/config/valve.html
  Note: The pattern used is equivalent to using
 pattern=common
 --
 Valve className=org.apache.catalina.valves.AccessLogValve
 directory=logs
prefix=localhost_access_log. suffix=.txt
pattern=%h %l %u %t quot;%rquot; %s %b /
 
   /Host
 
Host name=webapp1 appBase=/home/myhostid/tomcat/webapps
   Aliaswww.webapp1.com/Alias
   Aliasmyhostid.myserver.mywebhost.com/Alias
   Context path=/manager debug=0 privileged=true
   docBase=/home/myhostid/tomcat/webapps/manager
   /Context
/Host
   Host name=webapp2.com
 appBase=/home/myhostid/hosts/webapp2/webapps xmlValidation=false
 xmlNamespaceAware=false unpackWARs=true autoDeploy=true
   Aliaswww.webapp2.com/Alias
   Valve className=org.apache.catalina.valves.AccessLogValve
 directory=logs
prefix=webapp2_access_log. suffix=.txt
pattern=%h %l %u %t quot;%rquot; %s %b /
/Host
 /Engine
   /Service
 /Server
 
Kiran -
What no one has asked about yet is this:  What does your directory structure 
look like? Where are the catalina_home and catalina_base environment variables 
pointed?  Is it, I suspect, /home/myhostid/tomcat?
If so, then deployment of the server using the above config will result in the 
following:
For localhost and any request that comes in on the server's network interfaces 
that doesn't match your explicit host names or their alias, everything under 
the /home/myhostid/tomcat/webapps will be deployed once for the Host named 
localhost. So, for example http://localhost/webapp2/webapps/ would result in 
reaching the webapp2 pages (might need to add ROOT or webapp2 to the end, but 
you could reach it).
For the Host named webapp1, you will essentially re-deploy the 
application(s) that was deployed for localhost. We call that double-deployment, 
and it's something to avoid.
For the Host named webapp2.com, it will only deploy the application 
webapp2, but in so doing it will unpack the war into a directory named the same 
as the war file, which makes that application now available at the other hosts.

What I'm saying is, don't 

RE: unable to install tomcat7 on windows 2012 --- getting access denied

[Jeffrey Janner]

 -Original Message-
 From: George Sexton [mailto:geor...@mhsoftware.com]
 Sent: Thursday, April 30, 2015 10:44 AM
 To: users@tomcat.apache.org
 Subject: Re: unable to install tomcat7 on windows 2012 --- getting
 access denied
 
 
 
 On 4/30/2015 9:40 AM, Jeffrey Janner wrote:
  Turn off UAC, run the install, turn back on UAC.
 
 Or, run the command prompt as an administrator and then run the script.

He said he'd already tried that. I've had the UAC decide I'm not an Admin even 
when my user ID and/or group was a member of the Local Administrator's group on 
the machine. I've even seen it deny admin rights to commands run from and Admin 
console session - depending on the command.

 
 
  -Original Message-
  From: Eric Wood [mailto:eric.w...@irondata.com]
  Sent: Thursday, April 30, 2015 8:34 AM
  To: users@tomcat.apache.org
  Subject: unable to install tomcat7 on windows 2012 --- getting access
  denied
 
  Hi:
 
  I'm installing tomcat7 as a service on windows 2012 using the
 following
  command:
 
   Service.bat install
 
  I get an access denied message.  I'm and admin on the server as well
 as
  running the command from a command prompt as admin.
 
  Any idea what may be blocking me?
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 --
 George Sexton
 *MH Software, Inc.*
 Voice: 303 438 9585
 http://www.mhsoftware.com

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

RE: unable to install tomcat7 on windows 2012 --- getting access denied

[Jeffrey Janner]

Turn off UAC, run the install, turn back on UAC.

 -Original Message-
 From: Eric Wood [mailto:eric.w...@irondata.com]
 Sent: Thursday, April 30, 2015 8:34 AM
 To: users@tomcat.apache.org
 Subject: unable to install tomcat7 on windows 2012 --- getting access
 denied
 
 Hi:
 
 I'm installing tomcat7 as a service on windows 2012 using the following
 command:
 
 Service.bat install
 
 I get an access denied message.  I'm and admin on the server as well as
 running the command from a command prompt as admin.
 
 Any idea what may be blocking me?

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

RE: Post Session Id

[Jeffrey Janner]

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Monday, March 30, 2015 10:48 AM
 To: Tomcat Users List
 Subject: Re: Post Session Id
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Wesley,
 
 On 3/30/15 3:57 AM, Wesley Acheson wrote:
  On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz 
  ch...@christopherschultz.net wrote:
 
  Wesley,
 
  On 3/29/15 1:15 PM, Wesley Acheson wrote:
  A team I am working with use tomcat 7 as their web container.
  The application cannot use url session tracking due to
  compliance reasons.
 
  One of the requirements we are facing is that the
  application should work in an iframe on the safari web
  browser, which blocks all cookies.
 
  Do you mean that Safari has been configured to block all cookies?
  Because Safari won't block cookies just because you are using an
  iframe
  .
 
 
  Should have said its a third party domain name. That can't change
  easily. Should have wrote Safari blocks all third party cookies.
 
 Okay, that explains it.
 
 Let me ask you... why is a path parameter (;jsessionid=f00)
 unacceptable but not a request parameter? Or if it that you want to
 have the parameters be in POST-parameters only?
 
 In terms of forgery and/or capturing session identifiers, there's
 really no difference from a security perspective of any of these
 strategies.
 
 - -chris

I may be being a little naïve here, but would the sessionCookieDomain parameter 
of the Context element work for the OP here?

Jeff

RE: SSL Issue on the 443 port on tomcat7

[Jeffrey Janner]

 -Original Message-
 From: Vijay Karthick [mailto:vijaykarthic...@gmail.com]
 Sent: Thursday, March 19, 2015 11:11 AM
 To: users@tomcat.apache.org
 Subject: Fwd: SSL Issue on the 443 port on tomcat7
 
 Hi,
 
 In SAP BO environment, the SSL has been enabled in the Tomcat7 version.
 However, the Tomcat is not initializing. Its states that password error.
 I've recreated the keystore file. However, we're unable to fix it.
 Please
 refer the Log on the Tomcat folder.
 
 
 
 Server.xml :
 
 
 Connector port=443 protocol=HTTP/1.1 SSLEnabled=true
 
maxThreads=150 scheme=https secure=true
 
clientAuth=false sslProtocol=TLS
 maxHttpHeaderSize=65536 keystore=D:\SAP
 BusinessObjects\Tomcat6\conf\.keystore keypass=Password /
 
 
Please review the documentation on proper Connector configuration.
http://tomcat.apache.org/tomcat-7.0-doc/config/http.html

 
 The tomcat logs folder file stderr files give the below log,
 
 
 
 2015-03-18 23:10:01 Commons Daemon procrun stderr initialized
 
 Mar 18, 2015 11:10:02 PM org.apache.catalina.core.AprLifecycleListener
 init
 
 INFO: The APR based Apache Tomcat Native library which allows optimal
 performance in production environments was not found on the
 java.library.path: C:\Windows\SysWOW64\;D:\SAP BusinessObjects\SAP
 BusinessObjects Enterprise XI 4.0\win64_x64\
 
 Mar 18, 2015 11:10:02 PM
 org.apache.catalina.startup.SetAllPropertiesRule
 begin
 
 WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting
 property
 'keystore' to 'D:\SAP BusinessObjects\tomcat\conf\.keystore' did not
 find a
 matching property.
 
 Mar 18, 2015 11:10:02 PM
 org.apache.catalina.startup.SetAllPropertiesRule
 begin
 
 WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting
 property
 'keypass' to 'Password' did not find a matching property.
 
 Mar 18, 2015 11:10:02 PM org.apache.coyote.AbstractProtocol init
 
 INFO: Initializing ProtocolHandler [http-bio-443]
 
 Mar 18, 2015 11:10:03 PM org.apache.coyote.AbstractProtocol init
 
 SEVERE: Failed to initialize end point associated with ProtocolHandler
 [http-bio-443]
 
 java.io.IOException: Keystore was tampered with, or password was
 incorrect
 
   at
 sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:771)
 
   at
 sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:38)
 
   at java.security.KeyStore.load(KeyStore.java:1183)
 
   at
 org.apache.tomcat.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFac
 tory.java:407)
 
   at
 org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeystore(JSSESocket
 Factory.java:306)
 
   at
 org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESoc
 ketFactory.java:565)
 
   at
 org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESoc
 ketFactory.java:505)
 
   at
 org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory
 .java:449)
 
   at
 org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocke
 tFactory.java:158)
 
   at org.apache.tomcat.util.net.JIoEndpoint.bind(JIoEndpoint.java:393)
 
   at
 org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:6
 10)
 
   at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:429)
 
   at
 org.apache.coyote.http11.AbstractHttp11JsseProtocol.init(AbstractHttp11J
 sseProtocol.java:119)
 
   at
 org.apache.catalina.connector.Connector.initInternal(Connector.java:981)
 
   at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
 
   at
 org.apache.catalina.core.StandardService.initInternal(StandardService.ja
 va:559)
 
   at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
 
   at
 org.apache.catalina.core.StandardServer.initInternal(StandardServer.java
 :814)
 
   at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
 
   at org.apache.catalina.startup.Catalina.load(Catalina.java:633)
 
   at org.apache.catalina.startup.Catalina.load(Catalina.java:658)
 
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 
   at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
 a:39)
 
   at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
 Impl.java:25)
 
   at java.lang.reflect.Method.invoke(Method.java:597)
 
   at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281)
 
   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:450)
 
 Caused by: java.security.UnrecoverableKeyException: Password
 verification
 failed
 
   at
 sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:769)
 
   ... 26 more
 
 --
 *Regards,*
 Vijay Karthick S
 
 
 
 
 --
 *Regards,*
 Vijay Karthick S
 +91-9597957874

RE: Multiple SSL certificates on one Instance

[Jeffrey Janner]

 -Original Message-
 From: Rory Kelly [mailto:rory.ke...@fernsoftware.com]
 Sent: Monday, March 16, 2015 7:53 AM
 To: Tomcat Users List
 Subject: Multiple SSL certificates on one Instance
 
 Hey guys,
 
 
 
 I’ve a bad feeling what I’m trying to do is impossible, and I’m going to
 have to implement a different solution. Been hunting for an answer, but
 couldn’t find anything definite.
 
 I’m running Tomcat 8.0.18,
 
 Java 1.7.0_75-b13,
 
 Ubuntu 14.04.
 
 
 
 I have multiple sites running on Virtual Hosts on the instance. For a
 bit
 of background, I am intending on creating a 2-server load balanced
 system
 using nginx as a balancer on virtual servers (Best I can do, given our
 hosting/not possible to move away from it)
 
 I need each site to be protected by its own SSL certificate, provided by
 the client for each site.
 
 
 
 Can I actually have multiple SSL certs with Tomcat Virtual Hosts, or am
 I
 going to have to go learn nginx/httpd and provide it that way?
 
 
 
 Thanks,
 
 Rory

Rory -
The guys have all given some hints that this is probably coming, but not yet 
here. The rest of the answers depends on your ultimate requirements.
If you require that all the hosts are truly virtual, i.e. they all listen to 
the same IP-port combo, then it's definitely easier/better to terminate the SSL 
on your NGINX load-balancer, which presumably already has the needed support. 
There are some minor adjustments on the Tomcat connector config, but they are 
adequately explained in the Tomcat docs. Plus terminating on the load-balancer 
will save some processing cycles in Tomcat.
If you have the ability to assign multiple IP-port combo, then there's really 
only 1 way to do it on the Tomcat side: Create a unique Service tree for each 
host.  This tree will have its own Engine, Connector, Valve, Host, etc. 
entries, basically everything you might need that can't be put at the Global 
level. Be sure to specify both an HTTP and HTTPS connector so that TRANSPORT 
GUARANTEE will function properly.  Trying to do it all inside one Service 
tree is just asking for trouble.
If you go back in the archives a year or so, I think I posted a sample 
server.xml implementing the above.
Jeff

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

RE: Connection leak Tomcat7 and Oracle

[Jeffrey Janner]

Red -
Chris is describing exactly the way I configure my several dozen 
implementations, and I do not see the problems you are seeing.
I do not use global resources for exactly the reason he points out as well, I 
don't want to restart an entire Tomcat service just to update one app.
Also be sure to set the following parameters in your Host tags:
autoDeploy=false deployXML = false
It is really no harder to update several files than one.  And it insures the 
applications only have access to the connection pools they need, not all of 
them.
Jeff

p.s. Top posting to make my point more noticeable by OP.

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Friday, February 27, 2015 11:00 AM
 To: Tomcat Users List
 Subject: Re: Connection leak Tomcat7 and Oracle
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Red,
 
 On 2/27/15 11:04 AM, Red wrote:
  On 02/27/2015 06:58 AM, Антон Мацюк wrote:
  2015-02-27 1:36 GMT+02:00 Mark Thomas ma...@apache.org:
  On 26/02/2015 22:56, Christopher Schultz wrote:
 
  The solution is to put your Resource into your
  application's
  s/The solution/The best solution/
 
  context.xml and not into the site-wide defaults. Konstantin
  may not have spelled-out the solution, but he did give you
  all the information you needed to come to that conclusion on
  your own.
  Another (not so good because your application is no longer
  self-contained) option is to define a global resource and put
  a ResourceLink into the global context.xml or the application's
  context.xml.
 
  About not so good because your application is no longer
  self-contained - this is normal in case when tomcat is an
  sysadmin headache, and admin is bearing responsibility for both
  tomcat and pool in it works well. As a programmer - my job is to
  connect to provided datasource, and use it normally. So best
  approach in this situation will be use of GlobalNamingResources
  http://tomcat.apache.org/tomcat-7.0-
 doc/config/globalresources.html#Environment_Entries
 
 
 to store there my jdbc-pools and just make ResourceLink
  http://tomcat.apache.org/tomcat-7.0-
 doc/config/globalresources.html#Resource_Links
 
 
 in application's META_INF/context.xml to get this datasource from
  global context.
 
  -
 
 
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
  Thank You all; I have come to same conclusions, though they vastly
  differ from what I have expected. I have found spare Oracle Linux
  6.5 machine , downloaded latest tomcat 8.0.20, java is 1.7.0_65.
  Behaviour is the same, tomcat opens 50 conenctions to database.
  After moving pool definition from conf/context.xml to
  webapps/manager/META-INF/context.xml, tomcat opens 10 connections.
  Reading, then, this is default value of pool initial size (tenth of
  maxActive, default 100).
 
 You have maxActive=10. The default value of initialSize is supposed
 to be 0. I'm surprised it's opening 10 connections immediately.
 
  After explicitly defining initialSize=1, only single connection
  is opened.  Good. Now moving that pool definition back to
  conf/context.xml, I get five connections to db.  There is total 5
  apps deployed by default (ROOT. manager, hostmanager, docs and
  examples).  Basically, each app opens every connection pool defined
  in conf/context.xml to the tune of initialSize.
 
 Correct. This is exactly what you have asked Tomcat to do: define a
 default DataSource for all web applications. Note that it's *not a
 shared data source between all the web applications*. Instead, it's a
 DataSource that will be created for *each web application you deploy*.
 
 So, if the DataSource opens up 10 connections and you have 10 web
 applications, you'll get 100 connections to the database.
 
 (I'm not exactly sure why they are being opened immediately, but you
 are in fact getting 10 DataSources.)
 
  At my place we have about 25 applications in each dev and prod,
  with about 10-15 database pools defined.  Even with initialSize set
  to 1, that comes to total over 300 connections, which makes
  conf/context.xml useless for me.  If so, connections pools must be
  moved to application context.xml.
 
 You should be doing this anyway. It's very rare for a whole server
 full of applications to need the same DataSource configuration(s).
 
  Well, this is maintenance nightmare for me, as passwords are
  changed regularly, and I have to edit every single app context.xml
  file.
 
 Learn to script things.
 
  On top of it, we deploy .war files, and context.xml are part of
  it.
 
 If you use a separate deployment descriptor in
 conf/[engine]/[hostname]/[appname].xml, then the deployment descriptor
 in the WAR file will be ignored.
 
  In dev, I do not care, but for production, .war has to be packed
  with context.xml in it (with conn info).
 
 Does it?
 
  As a dba, 

RE: SSL issue in tomcat

[Jeffrey Janner]

 -Original Message-
 From: Jason Y [mailto:day...@gmail.com]
 Sent: Wednesday, January 21, 2015 12:44 AM
 To: Tomcat Users List
 Subject: Re: SSL issue in tomcat
 
 Got another issue...Tomcat is working fine after restart but it cannot
 last
 long.
 Now I cannot access https pages with any browsers. I didn't find
 anything
 useful in logs.
 After a restart, it works well again.
 
 Connector executor=tomcatThreadPool
port=8080 protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8443 /
 Connector port=8443
 protocol=org.apache.coyote.http11.Http11Protocol
maxThreads=150 SSLEnabled=true scheme=https
 secure=true
clientAuth=false sslProtocol=TLS
 sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1
 keystoreFile=lib/cert/.keystore
 keystorePass= /
 !-- Define an AJP 1.3 Connector on port 8009 --
 Connector port=8009 protocol=AJP/1.3 redirectPort=8443 /
 

Just a thought, but since it works for a while and then stops responding, could 
it be that the OP is running out of processing threads, i.e. a thread or 
connection pool leak?


 On Wed, Jan 21, 2015 at 10:01 AM, Sanaullah sanaulla...@gmail.com
 wrote:
 
  its not necessary to have ciphers properties but if you want to
 restrict
  the ciphers then you can use this property.
 
  On Wed, Jan 21, 2015 at 6:53 AM, Jason Y day...@gmail.com wrote:
 
   Thank you all. Now it is working fine.
  
   Connector port=8443
 protocol=org.apache.coyote.http11.Http11Protocol
  maxThreads=150 SSLEnabled=true scheme=https
   secure=true
  clientAuth=false sslProtocol=TLS
   sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1
   keystoreFile=lib/cert/.keystore keystorePass=
   ciphers=TLS_RSA_WITH_AES_128_CBC_SHA,
   TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA
 /
  
   By the way, do I need ciphers properties here?
  
   On Tue, Jan 20, 2015 at 11:22 PM, Christopher Schultz 
   ch...@christopherschultz.net wrote:
  
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
   
Jason,
   
On 1/20/15 4:17 AM, Jason Y wrote:
 Recently my application cannot be accessible in browser with
 https
 version. I think it is due to vulnerability in ssl 3.0 issue.

 I checked my tomcat configuration and replaced sslProtocol=TLS
 with sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2 to disable SSL
 3.0.

 Connector port=8080 protocol=HTTP/1.1
 connectionTimeout=2 redirectPort=8443 / Connector
 port=8443 protocol=org.apache.coyote.http11.Http11Protocol
 maxThreads=150 SSLEnabled=true scheme=https secure=true
 clientAuth=false sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2
 keystoreFile=xxx keystorePass=xxx / Connector port=8009
 protocol=AJP/1.3 redirectPort=8443 /
   
None of the responses you have gotten thus far are useful in any
 way.
   
Your configuration looks fine to me: sslEnabledProtocols is the
 way to
go, although in recent versions of Tomcat the default is NOT to
include any SSL protocols and only use the TLS ones, so if you
 are
running something recent, you should be okay.
   
 Then I can open my application https link in browser. BUT, good
 time never lasts too long, after several hours, I failed to
 access
 my https link again.
   
What kinds of errors do you get? What do the logs say? What are
 the
URLs you are using?
   
 Anyone has any ideas about this? please share your
 suggestions...My
 tomcat version is 7.0.55
   
Those SSL/TLS defaults I mentioned above were done in 7.0.57, so
 you
should definitely keep your above configuration. There is no need
 to
add a trust store or cipher specification to that.
   
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
   
iQIcBAEBCAAGBQJUvnKiAAoJEBzwKT+lPKRYQtsP/00rm7rdKVUID9YVQ4WJk3ty
JVQa/g0Kg4prYC+w5AFvZaiDK6EC014GKoTz4ktUzY4Ubnyd3vxsRTV+6/JOig0J
C9HcXKEZf63KS2uro71ymXNH0glDGJWtkCeTLR60elBUnyoOIat6ifQ9DqbH9BGT
nxJLRq4GZg8aaqKqToJNREY/6nX09+qmPYgpvzrdNlhDgxdb97o9hEPPQA85DMmG
mDMyP/TdnIcOdYa8n94/yFjaLQBqCAMl7li2VugbVMkSZMriz/NXnr52xTvZsFtH
8x4D5z5AzU+8+3P+vULmogW6418igLLWZHf03FAh2Wh5RKmvqKjaMzhC9qACYooJ
T7F1QfCZVqsEd5edzP17sUPjG62A1awwfMHB3/qmMpWz+Fde4taz2t+Pz652fugw
HrfhERRjkdpogfHmrAhBgZ/r89GpYlqEvMguW2PW6zL/ku51wx+aMfujrXO63+ZM
9psUeSvsR823foOYa6C3UV3MFbGWE7awUWuIBQi1bOxsP/ldKvEESGtdu9GpLHw7
A/5fyZ2a6+99HC56lvraGvPi+5ZI52Ej1mR0Ckk9RHRWqoCApTYsCzAPWd5Fntuq
zuNoyI6onNFKNDZ+17Nm55rywgHR/5hh5CLbf1PwSJRw2mJXbEnoXXUo1XoCS+Oo
G5/ksEFNFSc9+yQSSC1H
=PVop
-END PGP SIGNATURE-
   
--
 ---
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
   
   
  
 

RE: tomcat on windows 2012 weirdness

[Jeffrey Janner]

I noticed the ridiculous number of session issue on one of my servers, but it 
wasn't Windows 2012, but 2008 R2.  Don't think the windows version has anything 
to do with it, but something about the Tomcat version.
Looking at the manager, I had a couple hundred really old sessions, several 
hours expired, that were still showing up in the list.  When I click on the 
expire button, they all went away.
Noticed this when I was starting the upgrade to the latest Tomcat 7 release, 
and haven't checked back to see if it is still an issue since the upgrade.  If 
I get a little time later today, I'll recheck.
Jeff

 -Original Message-
 From: Cris Berneburg - US [mailto:cberneb...@caci.com]
 Sent: Thursday, December 11, 2014 10:28 AM
 To: users@tomcat.apache.org
 Subject: tomcat on windows 2012 weirdness
 
 Hi Folks
 
 I'm having trouble with my JSP web app using Tomcat 6 and 7 on Windows
 Server 2012.
 
 The issue is that no matter what file I request in the browser URL, it
 always returns the app welcome file, that is, the login page.  Even when
 requesting an image.  The one exception is that after logging in, the
 main menu page appears, but none of the graphics or CSS files load.
 Clicking on the app links, it just brings up the welcome page again.
 Checking the Tomcat log files, I see that Tomcat is returning the
 welcome page instead of the files requested in the main menu page.
 
 Using the Tomcat manager, I see that my application has a ridiculous
 number of sessions, instead of just one.  I interpret that for every
 single file requested, a new Tomcat session is being generated and
 possibly invalidated.
 
 FYI, using the same setup on Windows Server 2003 and 2008 works fine.
 Opening the same firewall ports on all three OS's has been done.  Even
 disabling the firewall on 2012 does not affect the issue in any way.
 And to make things even weirder, accessing the application from a
 browser on the server itself using localhost works fine!
 
 I wonder if there is some mystery setting somewhere that is crippling
 the app.  Got any suggestions?  Please help.  Thanks!
 
 --
 Cris Berneburg, Lead Software Engineer
 CACI, IRMA Project, 703-679-5313
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org


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

RE: tomcat on windows 2012 weirdness

[Jeffrey Janner]

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Thursday, December 11, 2014 3:10 PM
 To: Tomcat Users List
 Subject: Re: tomcat on windows 2012 weirdness
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Jeffrey,
 
 On 12/11/14 4:00 PM, Jeffrey Janner wrote:
  I noticed the ridiculous number of session issue on one of my
  servers, but it wasn't Windows 2012, but 2008 R2.  Don't think the
  windows version has anything to do with it, but something about the
  Tomcat version. Looking at the manager, I had a couple hundred
  really old sessions, several hours expired, that were still showing
  up in the list.  When I click on the expire button, they all went
  away. Noticed this when I was starting the upgrade to the latest
  Tomcat 7 release, and haven't checked back to see if it is still an
  issue since the upgrade.  If I get a little time later today, I'll
  recheck.
 
 I think this can happen if Tomcat's background processing thread dies.
 That can happen for a few reasons, including a transient OOME where
 the GC can catch-up once the offending thread (e.g.
 BackgroundProcessor) dies and releases its local references.
 
 Once that happens, sessions will never automatically die.
 
 I can't remember if clicking expire sessions (now) just wakes up the
 background thread (which would do nothing, of course), or if it
 synchronously does a cleanup (which would fix the issue, but only
 temporarily).
 
 - -chris
Thanks. I'll keep an eye out for it.
We had upgraded our app at the same time as moving to Tomcat 7.0.55 (or 56) and 
I noticed it when upgrading to 57 to get the latest security fixes.
Jeff

RE: Windows Service won't start

[Jeffrey Janner]

 -Original Message-
 From: David kerber [mailto:dcker...@verizon.net]
 Sent: Monday, November 10, 2014 12:23 PM
 To: Tomcat Users List
 Subject: Re: Windows Service won't start
 
 On 11/10/2014 1:04 PM, Christopher Schultz wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
 
  All,
 
  When a Tomcat Windows Service won't start (with the super-helpful a
  service-specific error occurred), where can I look for detailed
  information about what happened?
 
 Administrative Tools | Event Viewer is the app.  From there, the details
 depend on which version of Windows.  In Win7 and Server 2008 R2, it's
 under Windows Logs | System.
 
 The list in there can be quite large so it may take some scrolling, but
 you're looking for something with a Level value of Error.
 
 

The above may have something if you can't find it in the *_stderr.log or 
*_stdout.log file in the Tomcat logs directory.
I've almost always found the issue in one of those three places when I've had 
the error.

 
 
  (Please be kind, I'm not an everyday Windows administrator)
 
  I installed the service myself using a process almost exactly like this:
 
  C:\ SET CATALINA_HOME=[path to Tomcat]
  C:\ SET CATALINA_BASE=[path to my catalina.base]
  C:\ SET JAVA_HOME=[path to Java]
  C:\ %CATALINA_HOME%\bin\service.bat install myproject
 
  I can see the Windows Service called Apache Tomcat 7.0 myproject in
  the Services management console. Clicking start results in a short
  wait and then the error about how the service itself had a problem
  with no details.
 
  - From the CLI, running net start myproject yields a similar error.
 
  Any suggestions?
 
  Thanks,
  - -chris
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1
  Comment: GPGTools - http://gpgtools.org
 
 
 iQIcBAEBCAAGBQJUYP5FAAoJEBzwKT+lPKRYopwQAKMxxqY1nXTsJ6uTJAkqy
 ydW
 
 qegw3W5oNzh9Ai8M5PQlREA0ycCefwagOJbsUwfMrQPFrradtRLAG1YzFoCaf
 18M
  8K9f2bZLJ0YP07/q8f/cLsINDs5nHxoL8JK3RucH/jmUshtfYL7K6QKl25Segp3t
 
 bOv1p47uJBrZNbb0fVcsl1itPrz2CClKe+DKTRsWUbSgM062OM3Okbk97nAyCq
 o5
 
 Utu7Tzl5C1iZlF73bSo8F9Wx7p8z57775xv4jBRP3c8XUyQXYMfBzUwGDhvgge+
 z
 
 fbwlX6r7v3MjoRkTb39vvxqvkwqf7Ku/+J4o5tCW6oji8eSuKbVZNDOhIsTS8Ue
 V
 
 lnoYkGE3QxrrreczvHbMY3AwtRdBLoHkv7wCtgmYrUEhuB5l6dGIStZPyrkFEOj
 M
 
 3+pcTDE9bueOk8ivHxLCajn35GBfwNWj+LxTez7ggy0zxXY3G5Bzp5hVk1UWTq
 Zy
 
 dC/R7KpJ/4dPKQqjREEFW6U+G8rKlxXpGJMqEo+/QWVHkQl1EWN46kYRMSY
 whfCr
 
 V0ZQ9ETWsPRRCr5mXYXnWijqJWXaVDfJph29fjyyQnqQXjDgozwd4u3D0C+qJ
 FUg
 
 tdODD2HX7+HN/mAIv/5QENDRv4fIkw17gtG2M3Czkw9ZaH+DrF6p1EVX90OX
 XLCc
  szyMLbk3uRFJMbg/VXLG
  =ugtJ
  -END PGP SIGNATURE-
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org


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

RE: [ANN] Apache Tomcat Native 1.1.32 released

[Jeffrey Janner]

Any guestimate on when 7.0.57 is going to be released?
It is needed to get the TLSv1.1 + TLSv1.2 support that this implements.
With current releases, the only way to get the support is to not specify an 
sslProtocol, but that still enables SSlv3.
Jeff

 -Original Message-
 From: Mark Thomas [mailto:ma...@apache.org]
 Sent: Wednesday, October 29, 2014 3:44 AM
 To: Tomcat Users List
 Cc: Tomcat Developers List; annou...@apache.org;
 annou...@tomcat.apache.org
 Subject: Re: [ANN] Apache Tomcat Native 1.1.32 released
 
 On 28/10/2014 21:28, Mark Thomas wrote:
  The Apache Tomcat team announces the immediate availability of Apache
  Tomcat Native 1.1.32 stable.
 
  The key features of this release are:
  - Add support for TLSv1.1 and TLSv1.2
  - Link Windows binaries with OpenSSL 1.0.1i and APR 1.5.1
 
 Correction. OpenSSL 1.0.1*j*
 
 
  Please refer to the change log for the complete list of changes:
  http://tomcat.apache.org/native-doc/miscellaneous/changelog.html
 
  Downloads:
  http://tomcat.apache.org/download-native.cgi
 
  The Apache Tomcat Native Library provides portable API for features
  not found in contemporary JDK's. It uses Apache Portable Runtime as
  operating system abstraction layer and OpenSSL for SSL networking and
  allows optimal performance in production environments.
 
 
  Thank you,
 
 
 
 -
 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: Help with Apache Tomcat/7.0.53 SSL issue

[Jeffrey Janner]

 -Original Message-
 From: Brewer, Edward L [mailto:lee.bre...@vanderbilt.edu]
 Sent: Tuesday, October 07, 2014 1:36 PM
 To: Tomcat Users List
 Subject: RE: Help with Apache Tomcat/7.0.53 SSL issue
 
 To all,
 
 
 Oh...  Here is the entry in our server.xml  (probably the most important part)
 
 Connector port=Omitted address=Omitted protocol=HTTP/1.1
 SSLEnabled=true maxThreads=150 scheme=https secure=true
 clientAuth=false
 ciphers=SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_
 DHE_RSA_WITH_3DES_EDE_CBC_SHA keyAlias=omitted
 keystoreFile=/app001/shibboleth/idp/epass/current/credentials/idp.jks
 keystorePass=omitted /
 
 Connector port=omitted address=omitted
 protocol=org.apache.coyote.http11.Http11Protocol maxthreads=150
 scheme=https SSLEnabled=true secure=true clientAuth=want
 ciphers=SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_
 DHE_RSA_WITH_3DES_EDE_CBC_SHA keyAlias=omitted
 keystoreFile=/app001/shibboleth/idp/epass/current/credentials/idp.jks
 keystorePass=omitted /
 
 Users connect directly to first listed connection The second SSL port is 
 not
 currently used.
 
 Thanks,
 Lee
 
 From: Brewer, Edward L [mailto:lee.bre...@vanderbilt.edu]
 Sent: Tuesday, October 07, 2014 1:31 PM
 To: users@tomcat.apache.org
 Subject: Help with Apache Tomcat/7.0.53 SSL issue
 
 To all,
 
 I am using Apache Tomcat 7.0.53 and I am having an intermittent issue with
 SSL.  I am currently running three environments (Dev, UAT, and Prod. Prod
 comprises 4 VMs  (uname  states version as  2.6.32-431.11.2.el6.x86_x86_64
 GNU/Linux ) with each containing a local version of Java [ Java(TM) SE
 Runtime Environment (build 1.7.0_55-b13)  Java HotSpot(TM) 64-Bit Server
 VM (build 24.55-b03, mixed mode) ]  As well Tomcat and Java are owned by
 the user running the app.  The VMs are load balanced over two pair of LTMs
 (LTM1 balances node 1 and node 2;  LTM2 balances node 3 and node 4).  The
 test environment is scaled down to just one LTM with two nodes and
 development is just a single VM.
 
 Now, when I deployed dev and test I did not have any issues with SSL
 everything went as planned.  When I deployed into production, I started to
 get complaints about timeouts to the service.  After much troubleshooting...
 we were able to discern, using curl, that in production the LTM was not
 getting a response back from the application (using TCPDUMP)
 intermittently.   Our LTMs are configured to server as a SSL proxy.  On the
 VM, TCPDUMP shows that traffic is being presented to the socket but there
 is no response.  As far as I can tell the three environments (TOMCAT and
 JAVA) are the same.   I find nothing in the logs from both access and
 catalina.out.  When I restart the servers the problem goes away for about
 one hour then it comes back rapidly.  Using top and sar I do not see any
 issues with operating system performance.  Also,  by going done to one node
 the problem persists.  As well here are the options that are in setenv.sh
 
 export JAVA_OPTS=$JAVA_OPTS\
 -verbosegc\
 -Xms256m\
 -XX:+DisableExplicitGC\
 -Xmx2g
 
 
 Here is the error that I see from curl
 
 curl: (52) SSL read: error::lib(0):func(0):reason(0), errno 104
 
 Help,
 Lee Brewer

Lee, you say you checked the access  catalina logs, but did you check the 
stdout  stderr logs?
Since the problem goes away for about an hour after you restart, could you be 
having memory issues?  Those are usually reported in the stderr log.
Is 2g a valid value for -Xmx?  I've always specified it in terms of Megs, that 
is -Xmx2048m.
Jeff

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

Anyway to enable just all TLS protocols in APR connector?

[Jeffrey Janner]

Documentation for the APR connector says setting SSLProtocol=all (the 
default) enables TLSv1+SSLv3, but actually enables TLSv1.1 and TLSv1.2 as well. 
However, it only seems to accept SSLProtocol strings that includes TLSv1, 
SSLv2, SSLv3 or their combinations. In other words, there doesn't seem to be a 
way to specify that you only want all 3 TLS versions and none of the SSL 
versions.  Is there something I'm missing?

FYI: I checked Bugzilla on this, and there seems to be some work progressing on 
coding support, but it also interjected a regression to turn SSLv2 back on by 
default.
The question is, if there is no current magic string that Tomcat will accept 
to enable full TLS support, is this something we will have to wait for 7.0.57 
(and the equivalent 6  8 versions) to be able to address?

Jeffrey Janner

RE: Anyway to enable just all TLS protocols in APR connector?

[Jeffrey Janner]

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Friday, October 17, 2014 12:26 PM
 To: Tomcat Users List
 Subject: Re: Anyway to enable just all TLS protocols in APR connector?
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Jeffrey,
 
 On 10/17/14 1:12 PM, Jeffrey Janner wrote:
  Documentation for the APR connector says setting SSLProtocol=all
  (the default) enables TLSv1+SSLv3, but actually enables TLSv1.1
  and TLSv1.2 as well.
 
 Why do you think that's the case?

Qualys/SSLLabs reports it as such.  Using tomcat 7.0.50 and latest APR build.

 
  However, it only seems to accept SSLProtocol strings that includes
  TLSv1, SSLv2, SSLv3 or their combinations.
 
 Correct. Patches are in the works. Tomcat 7 and Tomcat 8 are patched;
 expect new builds soon.
 
  In other words, there doesn't seem to be a way to specify that you
  only want all 3 TLS versions and none of the SSL versions. Is
  there something I'm missing?
 
 Nope.
 
  FYI: I checked Bugzilla on this, and there seems to be some work
  progressing on coding support, but it also interjected a
  regression to turn SSLv2 back on by default.
 
 This can happen in certain situations, like saying that you want
 TLSvX+SSLv3 but no TLS versions are supported by OpenSSL. In that
 case, you get SSLv23 which I believe in OpenSSL means SSLv3 +
 SSLv2Hello which is only as dangerous as SSLv3 right now.

Actually, I was looking at the most recent patch code. It actually modified to 
definition of ALL to include SSLv2.
I pointed it out on Bugzilla, but thought I'd mention it here as well.

 
  The question is, if there is no current magic string that Tomcat
  will accept to enable full TLS support, is this something we will
  have to wait for 7.0.57 (and the equivalent 6  8 versions) to be
  able to address?
 
 Unfortunately, yes. You'll also need to wait for tcnative 1.1.32 as well.
 
With baited breath, but not holding it.

 
 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: GPGTools - http://gpgtools.org
 
 iQIcBAEBCAAGBQJUQVEbAAoJEBzwKT+lPKRYihIP/jDsBkjhmXZHe1EYQFzn4o
 X1
 hdujNBCt7MY3ZRnMJNZJ6UcjphK1AmdKdNAuGVWwLwOhHLwsmKsG9zwp
 ousdYwar
 /+HUeHpumJeeGxBPlbHW+ch9KVrKLkyfLR1wkmdh8PhdwCI7OcMqpYXipc1r
 R4bg
 s5/qRnlrONvSC4zYuI0W64P6zkZtFgtn0SMnWnc/eQ+8jGjkPuwfs91pvwDlMaY
 /
 pwE2cpVOK9VJU9h3hygL3apG1JYCeqmL2Cv+twuXXzGf2jvVUQQJCcFA6JxM
 ncpC
 PkEwM3OWn+BSuRaOS/mVXvNQE5XbLkgTaEQEKrjqv9wQD+Neally1g7Hrx3j
 ddky
 kTDSfJumJsSluBfl3XmWkVbYzSZ+02eQ4YI1NhqvNjyYBG+G2uToQFBkIti96kw
 6
 bJzL02fscG2T2sT2ISIQB5nyslwq4oMYsxSIM3dG9Gw0XIOB6cNVjfpVXhSKNa5
 Q
 Upf6GWA2E3bWZdgq4G5vvLeTJZWURXEutKwx4ocD6le/in1yCZqqjukqLFRlvL
 5w
 /OshW+ShaNIOOc7ZszHhLEFnPr2M984noFhOjpf1Zx0qr0If09voxnt+aYcAWjN
 c
 e23k6L9TyjA/goD0q9/TU5goVrZD6G/N3mifo94nhkG3J/IloH/JXxVTOwOLqmx
 w
 PNSWuKf02X3tAJ7ZnDGY
 =tLZz
 -END PGP SIGNATURE-
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Anyway to enable just all TLS protocols in APR connector?

[Jeffrey Janner]

 -Original Message-
 From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
 Sent: Friday, October 17, 2014 3:04 PM
 To: 'Tomcat Users List'
 Subject: RE: Anyway to enable just all TLS protocols in APR connector?
 
  -Original Message-
  From: Christopher Schultz [mailto:ch...@christopherschultz.net]
  Sent: Friday, October 17, 2014 12:26 PM
  To: Tomcat Users List
  Subject: Re: Anyway to enable just all TLS protocols in APR connector?
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
 
  Jeffrey,
 
  On 10/17/14 1:12 PM, Jeffrey Janner wrote:
   Documentation for the APR connector says setting SSLProtocol=all
   (the default) enables TLSv1+SSLv3, but actually enables TLSv1.1
   and TLSv1.2 as well.
 
  Why do you think that's the case?
 
 Qualys/SSLLabs reports it as such.  Using tomcat 7.0.50 and latest APR build.
 
 
   However, it only seems to accept SSLProtocol strings that includes
   TLSv1, SSLv2, SSLv3 or their combinations.
 
  Correct. Patches are in the works. Tomcat 7 and Tomcat 8 are patched;
  expect new builds soon.
 
   In other words, there doesn't seem to be a way to specify that you
   only want all 3 TLS versions and none of the SSL versions. Is
   there something I'm missing?
 
  Nope.
 
   FYI: I checked Bugzilla on this, and there seems to be some work
   progressing on coding support, but it also interjected a
   regression to turn SSLv2 back on by default.
 
  This can happen in certain situations, like saying that you want
  TLSvX+SSLv3 but no TLS versions are supported by OpenSSL. In that
  case, you get SSLv23 which I believe in OpenSSL means SSLv3 +
  SSLv2Hello which is only as dangerous as SSLv3 right now.
 
 Actually, I was looking at the most recent patch code. It actually modified to
 definition of ALL to include SSLv2.
 I pointed it out on Bugzilla, but thought I'd mention it here as well.
 

Chris, when I said most recent, I meant latest posted to the Bugzilla entry 
when I read it.
Just reviewed it again and see that's not the patch you guys are implementing.

 
   The question is, if there is no current magic string that Tomcat
   will accept to enable full TLS support, is this something we will
   have to wait for 7.0.57 (and the equivalent 6  8 versions) to be
   able to address?
 
  Unfortunately, yes. You'll also need to wait for tcnative 1.1.32 as well.
 
 With baited breath, but not holding it.
 
 
  - -chris
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1
  Comment: GPGTools - http://gpgtools.org
 
 
 iQIcBAEBCAAGBQJUQVEbAAoJEBzwKT+lPKRYihIP/jDsBkjhmXZHe1EYQFzn4o
  X1
 
 hdujNBCt7MY3ZRnMJNZJ6UcjphK1AmdKdNAuGVWwLwOhHLwsmKsG9zwp
  ousdYwar
 
 /+HUeHpumJeeGxBPlbHW+ch9KVrKLkyfLR1wkmdh8PhdwCI7OcMqpYXipc1r
  R4bg
 
 s5/qRnlrONvSC4zYuI0W64P6zkZtFgtn0SMnWnc/eQ+8jGjkPuwfs91pvwDlMaY
  /
 
 pwE2cpVOK9VJU9h3hygL3apG1JYCeqmL2Cv+twuXXzGf2jvVUQQJCcFA6JxM
  ncpC
 
 PkEwM3OWn+BSuRaOS/mVXvNQE5XbLkgTaEQEKrjqv9wQD+Neally1g7Hrx3j
  ddky
 
 kTDSfJumJsSluBfl3XmWkVbYzSZ+02eQ4YI1NhqvNjyYBG+G2uToQFBkIti96kw
  6
 
 bJzL02fscG2T2sT2ISIQB5nyslwq4oMYsxSIM3dG9Gw0XIOB6cNVjfpVXhSKNa5
  Q
 
 Upf6GWA2E3bWZdgq4G5vvLeTJZWURXEutKwx4ocD6le/in1yCZqqjukqLFRlvL
  5w
 
 /OshW+ShaNIOOc7ZszHhLEFnPr2M984noFhOjpf1Zx0qr0If09voxnt+aYcAWjN
  c
 
 e23k6L9TyjA/goD0q9/TU5goVrZD6G/N3mifo94nhkG3J/IloH/JXxVTOwOLqmx
  w
  PNSWuKf02X3tAJ7ZnDGY
  =tLZz
  -END PGP SIGNATURE-
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 B�KKK
 KCB��[��X��ܚX�KK[XZ[
 
 �\�\��][��X��ܚX�P�X�]
 �\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[
 
 �\�\��Z[�X�]
 �\X�K�ܙ�B�

RE: Anyway to enable just all TLS protocols in APR connector?

[Jeffrey Janner]

 -Original Message-
 From: André Warnier [mailto:a...@ice-sa.com]
 Sent: Friday, October 17, 2014 3:59 PM
 To: Tomcat Users List
 Subject: Re: Anyway to enable just all TLS protocols in APR connector?
 
 Bob Hall wrote:
  On Friday, October 17, 2014 1:05 PM, Jeffrey Janner
 jeffrey.jan...@polydyne.com wrote:
 
 
 
 
   With baited breath, but not holding it.
 
  Should be bated breath.
 
 
 But perhaps, dear Bob, Jeffrey meant exactly what he wrote.
 Having posted to the list and expecting a response,
 he rested with a glass of milk,
 waiting for the Tomcat to pounce.
 
 
I shall defer to those perhaps wiser than moi:
http://www.worldwidewords.org/qa/qa-bai1.htm

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

RE: Disabling SSLv3 with Tomcat ARP/Native but still retaining support for TLS 1.1 and TLS 1.2

[Jeffrey Janner]

 -Original Message-
 From: Mark Eggers [mailto:its_toas...@yahoo.com.INVALID]
 Sent: Wednesday, October 15, 2014 11:57 AM
 To: Tomcat Users List
 Subject: Re: Disabling SSLv3 with Tomcat ARP/Native but still retaining
 support for TLS 1.1 and TLS 1.2
 
 John,
 
 
  On Wednesday, October 15, 2014 6:20 AM, John Blaut
 john.bl...@gmail.com wrote:
   When SSLv3 is enabled, it seems TLS1.1 and TLS 1.2 are supported
 however.
  It seems strange that the SSLv3 option controls the availability of TLS1.1
  and TLS1.2.
 
  Now that SSLv3 is considered insecure and more people start to disable it,
  I suppose many on APR/Native will encounter the same issue.
  Is there any way to preserve TLS1.1  TLS1.2 whilst disabling SSLv3?
 
  Regards
 
  John
 
 
 From the Google blog post:
 
 Disabling SSL 3.0 support, or CBC-mode ciphers with SSL 3.0, is sufficient to
 mitigate this issue, but presents significant compatibility problems, even
 today.
 I run Apache HTTPD in front of Tomcat servers, so I think it will be possible 
 to
 disable the second (CBC-mode ciphers with SSL 3.0). I haven't really read the
 APR/Native SSL configuration carefully enough to know if this is possible with
 Tomcat.
 
 As an aside, for the last 500K hits I've seen 37 requests that have used CBC-
 mode ciphers with SSLv3. At least for the sites I am concerned with disabling
 this does not seem to have 'significant compatibility problems'.
 
 

Mark,
The APR connector does allow us to specify the list of supported ciphers with 
the SSLCipherSuite parameter and also allows us to specify that the list is in 
a preferred order with the SSLHonorCipherOrder parameter.
The list I am currently using comes from the Mozilla Wiki 
(https://wiki.mozilla.org/Security/Server_Side_TLS) which offers 3 different 
lists based on the browser compatibility that one requires. You should be able 
to disable the CBC ciphers in the list that you choose.
However, according to OpenSSL's own research 
(https://www.openssl.org/~bodo/ssl-poodle.pdf), this attack really leaves us 
with no secure cipher suites for SSL 3.0, so disabling SSLv3 is the way to go. 
The problem arises in the implementation of the APR connector in Tomcat.  While 
the native library supports and implements all versions of TLS when the all 
setting is used, there is no way to specify that you only want all the TLS 
protocols.  If you specify TLSv1, you will only get TLSv1.0, and not the two 
newer protocols, and if you try to use the usual TLSv1+TLSv1.1+TLSv1.2 you 
get an error. 
And on top of this, if you utilize the intermediate list found on the Mozilla 
Wiki, you end up with a list of TLS-only ciphers, but tools like Qualys will 
still ding you for having SSLv3.0 turned on at all, at not look at the list of 
ciphers.
Jeff

RE: Disabling SSLv3 with Tomcat ARP/Native but still retaining support for TLS 1.1 and TLS 1.2

[Jeffrey Janner]

FYI: My testing was done on 7.0.50. 
But from reading the Bugzilla entry on the issue, looks like we will need to 
wait on the next Tomcat 7 release.
Checking the last updates now, though.

 -Original Message-
 From: Mark Eggers [mailto:its_toas...@yahoo.com.INVALID]
 Sent: Thursday, October 16, 2014 11:30 AM
 To: Tomcat Users List
 Subject: Re: Disabling SSLv3 with Tomcat ARP/Native but still retaining
 support for TLS 1.1 and TLS 1.2
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 10/16/2014 9:17 AM, Jeffrey Janner wrote:
 
 
  -Original Message- From: Mark Eggers
  [mailto:its_toas...@yahoo.com.INVALID] Sent: Wednesday, October
  15, 2014 11:57 AM To: Tomcat Users List Subject: Re: Disabling
  SSLv3 with Tomcat ARP/Native but still retaining support for TLS
  1.1 and TLS 1.2
 
  John,
 
 
  On Wednesday, October 15, 2014 6:20 AM, John Blaut
  john.bl...@gmail.com wrote:
  When SSLv3 is enabled, it seems TLS1.1 and TLS 1.2 are
  supported
  however.
  It seems strange that the SSLv3 option controls the
  availability of TLS1.1 and TLS1.2.
 
  Now that SSLv3 is considered insecure and more people start to
  disable it, I suppose many on APR/Native will encounter the
  same issue. Is there any way to preserve TLS1.1  TLS1.2 whilst
  disabling SSLv3?
 
  Regards
 
  John
 
 
  From the Google blog post:
 
  Disabling SSL 3.0 support, or CBC-mode ciphers with SSL 3.0, is
  sufficient to mitigate this issue, but presents significant
  compatibility problems, even today. I run Apache HTTPD in front
  of Tomcat servers, so I think it will be possible to disable the
  second (CBC-mode ciphers with SSL 3.0). I haven't really read
  the APR/Native SSL configuration carefully enough to know if this
  is possible with Tomcat.
 
  As an aside, for the last 500K hits I've seen 37 requests that
  have used CBC- mode ciphers with SSLv3. At least for the sites I
  am concerned with disabling this does not seem to have
  'significant compatibility problems'.
 
 
 
  Mark, The APR connector does allow us to specify the list of
  supported ciphers with the SSLCipherSuite parameter and also allows
  us to specify that the list is in a preferred order with the
  SSLHonorCipherOrder parameter. The list I am currently using comes
  from the Mozilla Wiki
  (https://wiki.mozilla.org/Security/Server_Side_TLS) which offers 3
  different lists based on the browser compatibility that one
  requires. You should be able to disable the CBC ciphers in the list
  that you choose. However, according to OpenSSL's own research
  (https://www.openssl.org/~bodo/ssl-poodle.pdf), this attack really
  leaves us with no secure cipher suites for SSL 3.0, so disabling
  SSLv3 is the way to go. The problem arises in the implementation of
  the APR connector in Tomcat.  While the native library supports and
  implements all versions of TLS when the all setting is used,
  there is no way to specify that you only want all the TLS
  protocols.  If you specify TLSv1, you will only get TLSv1.0, and
  not the two newer protocols, and if you try to use the usual
  TLSv1+TLSv1.1+TLSv1.2 you get an error. And on top of this, if
  you utilize the intermediate list found on the Mozilla Wiki, you
  end up with a list of TLS-only ciphers, but tools like Qualys will
  still ding you for having SSLv3.0 turned on at all, at not look at
  the list of ciphers. Jeff
 
 Jeff,
 
 Thanks for pointing to the original research.
 
 . . . off to read SSL papers
 /mde/
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2
 
 iQEcBAEBAgAGBQJUP/J/AAoJEEFGbsYNeTwtgJEIAKOgt2Srt43+e+Jmns6DUd
 yM
 vfPR1jeefGhSq4ww1TO2Nmfhr2axXafrAGk//uIYSIDGhKvjc5enK6kHRDbSrR3I
 170rCdOIurrgtxoO99up1swmQMKTRlQv1SN1RKTOuN2BaoeIqvPFQ+qNcsxqI
 QHD
 jM7LfEiulHpyDXTBP1i+qb+c2ReX0FxcbjBuI+3+9DvEN+QMYrj+IP4A3Dcm4+Ld
 i+iN/eEe3FuE8TVOb/VrPhnWrihqvZMtWwocnDltBW6OC4/2BzVM+MMp1giU
 QC8w
 jHQwbXVkHTffL5i/DiIW1lHBSWNFu5+0qoiGDobRotM4chXp678NfwJozbo2fkY
 =
 =3A77
 -END PGP SIGNATURE-
 
 ---
 This email is free from viruses and malware because avast! Antivirus
 protection is active.
 http://www.avast.com
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

RE: WAR file deployment question

[Jeffrey Janner]

 -Original Message-
 From: James H. H. Lampert [mailto:jam...@touchtonecorp.com]
 Sent: Monday, September 15, 2014 7:11 PM
 To: Tomcat Users List
 Subject: WAR file deployment question
 
 We have a rather large WAR file. 89,925,956 bytes. And we have cable
 internet. With its usual extremely asymmetrical bandwidth: a download
 pipe the size of an air conditioning duct, and an upload pipe the size
 of an insulin needle.
 
 Squirting this huge WAR file through such a narrow pipe takes over half
 an hour. But our web and FTP servers are on a hosting service's server,
 so they're not passing through the narrow pipe.
 
 Can I, from Manager, deploy a WAR file that's sitting on a web or FTP
 site, instead of on my local system?
 
 --
 James H. H. Lampert

James,
The question becomes How does the war file get to the Web/FTP site? 
My supposition is from your local system through the same narrow pipe, so there 
is no real solution, you've just moved the delay to another step.
If that's not the case, then there are myriad ways.
The manager app only deploys war files in one of two ways: already on the 
server, or from the system running the browser.
So it sounds like some form of RDP is going to be necessary.
Jeff

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

RE: [SECURITY] CVE-2013-4444 Remote Code Execution in Apache Tomcat

[Jeffrey Janner]

 -Original Message-
 From: Mark Thomas [mailto:ma...@apache.org]
 Sent: Wednesday, September 10, 2014 9:00 AM
 To: Tomcat Users List
 Cc: Tomcat Developers List; annou...@apache.org;
 annou...@tomcat.apache.org; fulldisclos...@seclists.org;
 bugt...@securityfocus.com
 Subject: [SECURITY] CVE-2013- Remote Code Execution in Apache
 Tomcat
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 CVE-2013- Remote Code Execution
 
 Severity: Important
 
 Vendor: The Apache Software Foundation
 
 Versions Affected:
 - - Apache Tomcat 7.0.0 to 7.0.39
 
 Description:
 In very limited circumstances, it was possible for an attacker to upload
 a malicious JSP to a Tomcat server and then trigger the execution of
 that JSP. While Remote Code Execution would normally be viewed as a
 critical vulnerability, the circumstances under which this is possible
 are, in the view of the Tomcat security team, sufficiently limited that
 this vulnerability is viewed as important.
 For this attack to succeed all of the following requirements must be met:
 a) Using Oracle Java 1.7.0 update 25 or earlier (or any other Java
implementation where java.io.File is vulnerable to null byte
injection).
 b) A web application must be deployed to a vulnerable version of Tomcat
(see previous section).
 c) The web application must use the Servlet 3.0 File Upload feature.
 d) A file location within a deployed web application must be writeable
by the user the Tomcat process is running as. The Tomcat security
documentation recommends against this.

How does one avoid this if deploying war files?  By definition, doesn't the 
exploded directory need to be writable by the Tomcat process?
The only way I can think of is to not explode the war file, but that is a 
performance hit.

 e) A custom listener for JMX connections (e.g. the JmxRemoteListener
that is not enabled by default) must be configured and be able to
load classes from Tomcat's common class loader (i.e. the custom JMX
listener must be placed in Tomcat's lib directory)
 f) The custom JMX listener must be bound to an address other than
localhost for a remote attack (it is bound to localhost by default).
If the custom JMX listener is bound to localhost, a local attack
will still be possible.
 

Are these two an AND case?
If using the JmxRemoteListener, wouldn't one normally deploy it in Tomcat/lib?

Finally, if you've taken care of a)  b), is this sufficient to mitigate the 
problem, even if any/all of c) thru g) apply?

 Note that requirements b) and c) may be replaced with the following
 requirement:
 g) A web application is deployed that uses Apache Commons File Upload
1.2.1 or earlier.
 In this case a similar vulnerability may exist on any Servlet container,
 not just Apache Tomcat.
 
 Mitigation:
 This vulnerability may be mitigated by using any one of the following
 mitigations:
 - - Upgrade to Oracle Java 1.7.0 update 40 or later (or any other Java
   implementation where java.io.File is not vulnerable to null byte
   injection).
 - - Use OS file permissions to prevent the process Tomcat is running as
   from writing to any location within a deployed application.
 - - Disable any custom JMX listeners
 - - Upgrade to Apache Tomcat 7.0.40 or later
 
 Credit:
 This issue was identified by Pierre Ernst of the VMware Security
 Engineering, Communications  Response group (vSECR)  and reported to
 the Tomcat security team via the Pivotal security team.
 
 References:
 [1] http://tomcat.apache.org/security-7.html
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 
 iQIcBAEBAgAGBQJUEFl4AAoJEBDAHFovYFnnR3cQAL034ZrbUeBcJ4zotNp5+ea
 2
 llNatC3MUlg/vZ2qG8Qo4xxbdS4F53cpu90fFhKm+dFzIiRhZeHROYDv6Lu1biSu
 Nvq0YXV6KVJ9Js4G6HFilhy3vownvn/hMAjzmPojSYjWO5slXNfFvAlwyRrGt0C
 p
 t5rUh4QNavhgO4m0HXJJLg+PNlSKsnGdra+0gWmq8YKtKotgu24SbPq/p3HP7T
 uJ
 nnMjx4A6r2LcoghL/nFAPp2ZwgBCtm67osObJ1uMxYhZ2I/3MztFYpSKvfVONu
 UK
 rL265wmrKLvvDdozd/Aw2d2poXdSO/oWeuhKbbzYOxpUT6iRzf+BkPUR99e6R
 qso
 lOfLoAYuzYfK4rW/ooxVNKnHMhs+0BVfNZoclKCDSvz+a9dIVS5XD6KcyJQ3uv1
 2
 ujyTGaGhLuS/ciAVS372Dx8H0/mfd5nZCkYL6NDyzSWSmb5eG4XxqrLi77yByvA
 T
 ulSAyg1UWk8sRgQ4AY3belH3jDiN1rHSWJAaB+WVwszQdCe4iXgDyB1u4ES22
 oAN
 Ymrg5l7tLQ8/9LyMvlQ0tE4f+OYE6kki6e4JMc2cMqPL/rcjiUnLWZ7YUyx92RM1
 LRt9QhMd1h3Uwle7a7LxqJCGf/rIPwRmrjTYYWt43np1Adx7y2RuZOTDjEY98sN
 3
 oCLjuSCalVcBX9hGaJ7n
 =98BB
 -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: Windows performance issue

[Jeffrey Janner]

 -Original Message-
 From: Omar Orzenini [mailto:omar.orzen...@gmail.com]
 Sent: Monday, July 21, 2014 6:42 AM
 To: Tomcat Users List
 Subject: Re: Windows performance issue
 
 Thank you all for the answers. I performed these tests because we are
 showing serious performance problems on WIndows configurations for load
 balancing (a file server shares the webapps folder via SMB for two
 different application
 servers that map the webapps via UNC. Tried both mapping the folder via
 UNC
 and as logical drive but i did not get great results.
 
 
With that stated use case, it would be far safer to rethink your deployment 
scenario.
With multiple Tomcats sharing the webapps directory, you run the risk of 
problems occurring because each Tomcat will want to explode the war files into 
a sub-tree structure, potentially causing problems for a server that is already 
running. I am sure there are more knowledgeable folks here that can address 
that scenario.  You could, of course, turn off the explode warfiles setting and 
that would reduce that issue, but running from warfiles has its own performance 
hit.
Might I suggest pointing webapps to an empty directory and using the docbase 
parameter of the Context to point to the shared directory structure with 
pre-exploded war file sub-trees?
Of course, if the problem is really with SMB bottlenecks, that probably won't 
be that much more helpful.
Q: Why bother with the shared directory issue at all?  How about just copying 
the war file to each server and let them run from their local copies? That 
would result in the best performance.
(note: this is what I do for my customer base and don't find it all that 
burdensome to roll out an upgrade for 100+ customers.)
Jeff

RE: Host appBase vs Context docBase

[Jeffrey Janner]

-Original Message-
From: Igal @ getRailo.org [mailto:i...@getrailo.org] 
Sent: Friday, July 04, 2014 9:05 PM
To: Tomcat Users List
Subject: Host appBase vs Context docBase

I'm a little confused about the Host appBase attribute.

Let's say that my website resides in D:\www\site1

I don't like using {Tomcat}/webapps so I don't want to have it as a base 
directory for websites.  What I've been doing so far is create an empty 
folder alongside webapps, named empty, and use it as appBase, e.g.

Host name=Site1 appBase=empty unpackWARs=false autoDeploy=false
   !-- this works but what's the deal with appBase? !--
   Context path=/ docBase=D:/www/site1 /
/Host

But it feels like I'm doing something wrong.  I expect this to work, but 
it doesn't:

Host name=Site1 appBase=D:/www/site1 unpackWARs=false 
autoDeploy=false
   !-- this doesn't work !--
/Host

Can anyone explain why the snippet above doesn't work, and if that is 
the way it should be, then what is the purpose of Host/appBase?

TIA

-- 
Igal Sapir
Railo Core Developer
http://getRailo.org/

Igal -
For the way you want to configure your setup, your original configuration will 
work, except that you need to change the path from / to .
That's kind of the one thing bothered me from the beginning: if you wanted a 
named path, like virtdir you have to specify it with a leading slash, 
/virtdir but for the ROOT you don't specify it. Seemed like an inconsistent 
treatment to me.
That said, I'd really recommend following current practices and moving the 
Context element to its own file under the conf/engine_name/host_name 
directory structure.  For one, you don't have to worry about that path 
parameter ever again. The name of the XML file becomes the path value, with the 
exception of needing to name the file ROOT.xml to get the null path. Also, this 
allows you to store the file under the META-INF directory of your application 
and maintain the information there and have it copied to the correct place on 
deployment.  Read the docs for more info.
Here's how to remember the difference between appbase and docbase:  The appbase 
is the path to a directory where the applications for the host reside.  Any 
directory or war file stored there will be deployed under the host.
The docbase is the path to the directory containing the files for a specific 
application.  If it is a relative path, the directory is expected to reside 
under the appbase (take care to avoid double-deployment).  If it is a 
fully-qualified path, then the appbase value is ignored. 
It is possible to mix the two, but you need to be careful if you attempt that. 
Creating a new directory for each host is a good idea, even if they are empty.
If I were you, I'd really look at moving to the current configuration 
mechanism.  After you get used to it, you'll see it makes a lot more sense.  As 
an added plus, any change you make to the context can take effect without 
having to restart the entire Tomcat service.
Jeff



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

RE: CVE-2014-0224

[Jeffrey Janner]

 From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] 
 Sent: Wednesday, June 25, 2014 6:05 PM
 To: 'Tomcat Users List'
 Subject: CVE-2014-0224

 Does anyone know of a way to mitigate this vulnerability until the latest 
 OpenSSL patch can be applied to the Native Libraries?
 Perhaps limiting the cipher list to the list of strongest ciphers available 
 that are supported by the major browsers?
 Is there a listing somewhere of the cipher lists supported by those browsers?

Answering my own post after doing a little googling (Google is Your Friend. 
Trust the Google.) Actually, Redhat is providing the answer:

There is no known mitigation for this issue. The only way to fix it is to 
install updated OpenSSL packages and restart affected services.

The vulnerability can only be exploited if both server and client are 
vulnerable to this issue. In the event that one of the two is vulnerable, there 
is no risk of exploitation.




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

CVE-2014-0224

[Jeffrey Janner]

Does anyone know of a way to mitigate this vulnerability until the latest 
OpenSSL patch can be applied to the Native Libraries?
Perhaps limiting the cipher list to the list of strongest ciphers available 
that are supported by the major browsers?
Is there a listing somewhere of the cipher lists supported by those browsers?

Jeffrey Janner
Sr. Network Administrator
jeffrey.jan...@polydyne.commailto:first.l...@polydyne.com
PolyDyne Software Inc.
Main:   512.343.9100
Direct:  512.583.8930

 [cid:image002.png@01CC0FB7.4FF43CE0]

Speed, Intelligence  Savings in Sourcing

RE: Browsers suddenly start timing out when accessing port 80 of secure site

[Jeffrey Janner]

 -Original Message-
 From: Bruce Lombardi [mailto:brlom...@gmail.com]
 Sent: Thursday, June 19, 2014 11:33 AM
 To: users@tomcat.apache.org
 Subject: Browsers suddenly start timing out when accessing port 80 of
 secure site
 
 We have a Java application running on Tomcat 7.0.52 on an Amazon Web
 Services EC2 Windows 2008 R2 server. Tomcat is setup so that our
 application is the root application and is accessible from port 80. The
 application and Tomcat are configured with SSL so that whenever anyone
 types in the url for the site (e.g. www.something.net) Tomcat will
 switch into HTTPS and use port 8443.
 
 This all works fine, but it seems that if for some reason a browser
 times out when accessing the site, it will never connect to the site
 again, and any attempt to connect using www.something.net will show
 that the connection has timed out. Yet if you put in the port number
 (e.g.,
 www.something.net:8443) it comes up right away. We have seen this
 happen on both Chrome (Version 35.0.1916.153 m) and Firefox (Version
 30.0).
 
 On Chrome I was able to get the browser to connect to the site by going
 to Settings  Advanced  Clear Browser Data and clearing browser
 history, download history, cookies, and cached images and files. Once I
 did that the site came up immediately with www.something.net and switch
 to HTTPS as it is supposed to do.
 
 On Firefox, I get the same thing. It will not connect unless I add the
 port.
 I tried clearing cached web content, setting the cache limit to zero,
 and clearing offline web content. None of this worked. Re-installing
 Firefox did work.
 
 It took me several months to encounter this problem. But other users
 have encountered it right away (e.g., when setting up a new machine).
 
 Using browser development tools and Tomcat logs, I was able to see the
 following:
 
 . When working chrome send get to url. Tomcat responds with
 HTTP 302
 and redirects to the secure port. The Tomcat localhost_access_log
 reflects these transmissions.
 
 . When not working, Firefox sends get to url, but no response
 is
 returned. The Tomcat localhost_access_log is blank.
 
 Can anyone shed any light on this? Is this a Tomcat issue or something
 to do with the browsers? Is there anything I can look for in the logs
 that may help?
 
 Bruce

Sounds like a browser issue to me, Bruce, unless you've got something else in 
your topology that could be causing the issue. Say a proxy, for instance? Also, 
are you sure on the subsequent attempts that your URL starts off with http:// 
and not https://.  It's a pretty easy detail to overlook.

And on a just curious basis:  Why redirect to 8443 instead of the standard 
HTTPS port of 443? Then you wouldn't need the port number in the URL.


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

RE: Tomcat 8.0.5 Windows 7 service removal is incomplete

[Jeffrey Janner]

 -Original Message-
 From: Gerry Matte [mailto:ge...@gerrymatte.ca]
 Sent: Wednesday, June 18, 2014 11:53 AM
 To: users@tomcat.apache.org
 Subject: Tomcat 8.0.5 Windows 7 service removal is incomplete
 
 On May 21, I installed the windows service version of tomcat 8.0.5 in
 order to test an application which required it.
 I installed the version that creates a windows service named Tomcat8
 
 I subsequently discovered the application was tested with tomcat7 so I
 removed the service using [CATALINA_HOME]\bin\service.bat remove
 The following day, when I started my PC I encountered a startup error
 popup saying The specified service does not exist.  Unable to open an
 installed service named Tomcat8
 
 I reinstalled the service using [CATALINA_HOME]\bin\service.bat
 install
 and then uninstalled it using the command [CATALINA_HOME]\bin\tomcat8
 //DS//Tomcat8 as documented on the tomcat website at
 http://tomcat.apache.org/tomcat-8.0-doc/windows-service-howto.html
 (Removing Services)
 
 When I restart my PC, I still encounter the error popup message.
 
 I used MSCONFIG to look for a phantom startup request for Tomcat8 but
 it did not seem to be present on the list of start-ups.
 
 Can anyone suggest what else I can do to expunge the Tomcat8 service ?
 Thanks
 Gerry Matte
 
Gerry -
I'm not 100% sure about this, but it sounds like the error message you get when 
the service manager starts up (Tomcat8w, sits in the system tray). You don't 
mention how you did the original install, but the binary installer installs 
this service manager, along with Start Menu entries, etc. If you used the 
binary installer, use add/remove programs to remove everything it did for you.  
Otherwise, it's a trip down the registry tree looking for RUN/RUNONCE entries.
Jeff
p.s. I'm a big believer in using the binary installer. It does almost 
everything I need these days. Kudos to the developer who maintains this.



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

RE: Tomcat is down or refused connection

[Jeffrey Janner]

 -Original Message-
 From: Mark Eggers [mailto:its_toas...@yahoo.com]
 Sent: Friday, May 23, 2014 7:53 PM
 To: users@tomcat.apache.org
 Subject: Re: Tomcat is down or refused connection
 
 On 5/23/2014 5:34 PM, Terence M. Bandoian wrote:
  On 5/23/2014 1:22 AM, Ballarpure, Akshay (EXT-Tata Consultancy Ser -
  IN/Hyderabad) wrote:
 
 
  Hello,
  Soap request is failing with below message in our application.
 
  2014/05/20 06:48:43 [ERROR]   (browse_csl)   failed to
  reach startSearch service, soapRC 502
  2014/05/20 06:48:43 [ERROR]   (soap)Error 502
  fault: SOAP-ENV:Server [no subcode]
 
  I am seeing below messages in Apache's Mod JK log file.
 
  [Tue May 20 06:48:43 2014] [57070:140373099702016] [error]
  ajp_get_reply::jk_ajp_common.c (2126): (worker1) Tomcat is down or
  refused connection. No response has been sent to the client (yet)
  [Tue May 20 06:48:43 2014] [56884:140373020112640] [error]
  ajp_service::jk_ajp_common.c (2643): (worker1) connecting to tomcat
  failed.
 
  Could you please check and let me know the reason for the above ?
 
  Thanks,
  Akshay
 
 
  Sounds like Tomcat is down.
 
  -Terence Bandoian
 
 Sounds like your application is broken, or Tomcat is down, or someone
 unplugged a network cable, or someone changed firewall rules, or . . .
 
 Seriously, you have given us no information.
 
 And by no, I mean all of this is missing:
 
 1. architecture
 a. Apache HTTPD (I'm guessing yes)
 b. mod_jk versus mod_proxy_ajp
 c. intervening firewalls
 d. number of Tomcats being supported
 e. load balancing or not
 f. using Tomcat native or not
 2. versions - of anything
 a. Apache HTTPD (or whatever else you're using here)
 b. Tomcat version - exact, please
 c. Java version - exact, please
 d. OS and version - exact please
 3. Tomcat settings - primarily JVM settings 4. Configurations
 a. server.xml
 b. workers.properties - if that's what you're using
 c. Apache HTTPD configuration - if that's what you're using 5. Log
 files - more than what you've provided
 a. catalina logs (Tomcat logs around the time of the event)
 b. application logs (around the time of the event) 6. What is this
 application supposed to be doing??
 
 There is more, but this is a good start.
 
 A 502 normally means that servers can't talk to each other. This could
 mean that Tomcat is down, it could mean that an intervening firewall
 has dropped connections, it could mean many, many things.
 
 Don't know without lots more information.
 
 . . . . it's Friday, welcome to more than my 2 cents /mde/
 

Mark -
Most importantly, he failed to provide the remote access information for the 
servers involved and their admin account names and passwords so that we could 
get in there and look around until we figured out what the problem was.
Jeff

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

RE: tomcat6 thread locked

[Jeffrey Janner]

 -Original Message-
 From: devoss ind [mailto:devoss@gmail.com]
 Sent: Tuesday, May 20, 2014 8:29 PM
 To: Tomcat Users List
 Subject: Re: tomcat6 thread locked
 
 Hi Christopher,
 
 Can you suggest stable tomcat and jvm versions.
 
 Regards,
 Devoss.
 

I can:  Java 7u55 (1.7.0_55) and Tomcat 7.0.53
Just so happens these are the latest versions of both product.
Jeff

Is the listserv down?

[Jeffrey Janner]

Last message I got was Mark notifying Martin he was toast.
That was 2 days ago.

Jeffrey Janner
Sr. Network Administrator
jeffrey.jan...@polydyne.commailto:first.l...@polydyne.com
PolyDyne Software Inc.
Main:   512.343.9100
Direct:  512.583.8930

 [cid:image002.png@01CC0FB7.4FF43CE0]

Speed, Intelligence  Savings in Sourcing

RE: Unable to unpack war under webapps

[Jeffrey Janner]

 -Original Message-
 From: Rahul R [mailto:rahul.ra...@gmail.com]
 Sent: Tuesday, May 06, 2014 8:25 AM
 To: users@tomcat.apache.org
 Subject: Unable to unpack war under webapps
 
 Hi
 
 I have put ROOT.war under webapps folder of tomcat. When I start the
 instance I am getting the below error on catalina.out.
 
 INFO: Deploying web application archive /opt/tomcat-
 proxy/webapps/ROOT.war
 May 06, 2014 6:28:22 PM org.apache.catalina.startup.ContextConfig
 beforeStart
 SEVERE: Exception fixing docBase for context [/ROOT]
 java.io.IOException: Unable to create the directory [/opt/tomcat-
 proxy/webapps/ROOT]
 
 I am not sure why this is happening. Checked the permissions on webapps
 folder as well as the war file. Its 755.
 
 P.S: I am able to use jar to unpack it manually under webapps.

Who is listed as owner/group on the webapps directory?
What user is Tomcat running under?

RE: How to monitor performance of tomcat

[Jeffrey Janner]

 -Original Message-
 From: Randhir Singh [mailto:randhir.si...@sterlite.com]
 Sent: Monday, April 21, 2014 5:17 AM
 To: Tomcat Users List
 Subject: RE: How to monitor performance of tomcat
 
 Hi,
 
 I wanted input from the experts on my query below that the port 8891
 does not respond when the command,
 
 jconsole 10.101.17.79:8891
 
 is issued when the application hangs and stops responding.
 
 Requesting inputs so that the root cause analysis of this issue can be
 found out.
 
 Regards
 
Randhir -
Your actual first request in this thread was apparently a request for opinions 
on monitoring tools.
This problem of actual hangs wasn't brought up until a week later.
Here is what I've usually found when Tomcat stops responding and even the 
monitoring port is unreachable via jconsole and other tools: Your JVM has 
crashed for some reason.
At this point, you need to refer to the Tomcat logs, your application logs, 
etc. in order to find the root cause.  If the JVM is still running, try 
taking a couple of thread dumps and review them to find your root cause.
Jeff

RE: Configuration question

[Jeffrey Janner]

 -Original Message-
 From: Mark Murphy [mailto:jmarkmur...@gmail.com]
 Sent: Thursday, April 17, 2014 9:01 AM
 To: Tomcat Users List
 Subject: Re: Configuration question
 
 Here is the configuration, as you can see the default host is set and
 the IP is not aliased.
 
 in server.xml
 ...
 Connector port=80 protocol=HTTP/1.1
connectionTimeout=2
redirectPort=443 /
 ...
 Connector protocol=org.apache.coyote.http11.Http11NioProtocol
port=443
scheme=https secure=true SSLEnabled=true
keystoreFile=xxx.keystore
keystorePass=xxx keyAlias=xxx
clientAuth=false sslProtocol=TLS / ...
 Engine name=Catalina
 defaultHost=www.torquewrenchrecalibration.com
 ...
   Host name=www.torquewrenchrecalibration.com  appBase=webapps
 unpackWARs=true autoDeploy=false
 xmlValidation=false xmlNamespaceAware=false
 Aliaswww.torque-wrench-recalibration.com/Alias
 Aliaswww.myerstorquetracker.com/Alias
   /Host
 ...
 
 in web.xml
 ...
 security-constraint
   web-resource-collection
 web-resource-nameEntire App/web-resource-name
 url-pattern/*/url-pattern
   /web-resource-collection
   user-data-constraint
 transport-guaranteeCONFIDENTIAL/transport-guarantee
   /user-data-constraint
 /security-constraint
 ...
 
 
 
Well, with that configuration, any traffic sent to your IP address will be 
directed to your default host, i.e. your app, so that settles the question 
about the IP or DNS name generating the error on the WSS.  Both should return 
the same result.  So, either the WSS doesn't know what it's talking about, or 
you're not getting the message because of the connection to your login page. I 
don't see any reference to any Tomcat-initiated authentication defined here, so 
perhaps it’s a problem with the WSS, or as Terrence pointed out, do you have 
the manager app deployed?  By default, it uses Basic Auth and non-SSL.  You 
might need to spruce up the security on it a bit.
Jeff 

RE: Configuration question

[Jeffrey Janner]

 -Original Message-
 From: Mark Murphy [mailto:jmarkmur...@gmail.com]
 Sent: Wednesday, April 16, 2014 12:42 PM
 To: Tomcat Users List
 Subject: Configuration question
 
 How do I prevent Tomcat 6 from responding to a request to an IP
 address, that is I only want my Tomcat server to respond to requests to
 www.mydomain.com vs. 10.1.1.1.
 
 Is this possible?
 
To address the question asked:
The easiest way may be to create a dummy Host entry with an Alias entry for 
the IP Address. Do not allocate any contexts to the host, or perhaps one that 
points to an empty directory.  Haven't tested it, just a thought.
However read rest of answer.

 The problem is that our web security scanner is reporting Web Server
 Uses Basic Authentication Without HTTPS, and the infrastructure guys
 think it is because Tomcat allows connection to the IP address.
 
 Does this make sense?
No this does not make sense.  If the IP isn't returning HTTPS, then your DNS 
name probably isn't either. Tomcat doesn't care about the supplied name, except 
to match it to the Host entry in server.xml.  You didn't post your config, 
but I'm assuming that the default host is set to www.mydomain.com, and the IP 
address isn't aliased. If it is not that way, you should either correctly set 
your default host, or add an Alias entry for the IP address to you Host 
config.

You'd definitely get this response if your default host was still set at the 
default of localhost, instead of your Host entry's name value, there was no 
Alias entry for the IP, and the security tester was testing against IP as 
well as name (though one would expect the report to indicate this).

RE: How to monitor performance of tomcat

[Jeffrey Janner]

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Friday, April 11, 2014 12:54 AM
 To: Tomcat Users List
 Subject: Re: How to monitor performance of tomcat
 
 All,
 
 On 4/8/14, 5:24 PM, Christopher Schultz wrote:
  Randir,
 
  On 4/8/14, 5:05 AM, Randhir Singh wrote:
  We have an application which has JBoss as the application server
 with
  Tomcat as the web server, our application has Oracle 11g as the
  database. I would give some further background to the issue we are
  facing, since the last 1 1/2 months, the application slows down.
  Sometimes it comes back to normal, specially on week-ends. But other
  times we restart JBoss  Tomcat to bring back the application to
  normal.
 
  We have been using jconsole to monitor tomcat like
 
  jconsole 10.101.17.79:8891
 
  which monitors our tomcat for a work order system. If the memory
  usage does not show spike and shows constant reading, the GC button
  is clicked to invoke the garbage collector.
 
  You should really never have to invoke the gc yourself. It gc isn't
  working properly by itself, you have a big problem.
 
  I checked out on the net and got some clue as below:
 
  1)  Javamelody - It seems to be a 3rd party tool which is not
   recommended.
 
  Javamelody is just fine. What makes you think it's not recommended?
 
  2)  There is a command mentioned to see the admin console,
  http://IP:port/ but it is not displaying the required page.
 
  Please give your inputs whether jconsole should be a help in the
  right direction or some other way to monitor the performance of
  Tomcat.
 
  I suspect there's no chance you are in Denver for ApacheCon right
 now,
  are you? I'm giving a presentation on it tomorrow. I'll post the
  slides later in the afternoon MDT.
 
 http://people.apache.org/~schultz/ApacheCon%20NA%202014/Monitoring%20Ap
 ache%20Tomcat%20with%20JMX.odp
 
 There's a PDF version with borked slide-notes in that directory if you
 can't read ODP.
 
Chris -
The PDF file is not world readable.
Jeff

RE: How to monitor performance of tomcat

[Jeffrey Janner]

 -Original Message-
 From: André Warnier [mailto:a...@ice-sa.com]
 Sent: Friday, April 11, 2014 9:27 AM
 To: Tomcat Users List
 Subject: Re: How to monitor performance of tomcat
 
 Jeffrey Janner wrote:
  -Original Message-
  From: Christopher Schultz [mailto:ch...@christopherschultz.net]
  Sent: Friday, April 11, 2014 12:54 AM
  To: Tomcat Users List
  Subject: Re: How to monitor performance of tomcat
 
  All,
 
  On 4/8/14, 5:24 PM, Christopher Schultz wrote:
  Randir,
 
  On 4/8/14, 5:05 AM, Randhir Singh wrote:
  We have an application which has JBoss as the application server
  with
  Tomcat as the web server, our application has Oracle 11g as the
  database. I would give some further background to the issue we are
  facing, since the last 1 1/2 months, the application slows down.
  Sometimes it comes back to normal, specially on week-ends. But
  other times we restart JBoss  Tomcat to bring back the
 application
  to normal.
  We have been using jconsole to monitor tomcat like jconsole
  10.101.17.79:8891 which monitors our tomcat for a work order
  system. If the memory usage does not show spike and shows constant
  reading, the GC button is clicked to invoke the garbage collector.
  You should really never have to invoke the gc yourself. It gc isn't
  working properly by itself, you have a big problem.
 
  I checked out on the net and got some clue as below:
  1)  Javamelody - It seems to be a 3rd party tool which is not
   recommended.
  Javamelody is just fine. What makes you think it's not
 recommended?
 
  2)  There is a command mentioned to see the admin console,
  http://IP:port/ but it is not displaying the required page.
  Please give your inputs whether jconsole should be a help in the
  right direction or some other way to monitor the performance of
  Tomcat.
  I suspect there's no chance you are in Denver for ApacheCon right
  now,
  are you? I'm giving a presentation on it tomorrow. I'll post the
  slides later in the afternoon MDT.
 
 http://people.apache.org/~schultz/ApacheCon%20NA%202014/Monitoring%20
  Ap
  ache%20Tomcat%20with%20JMX.odp
 
  There's a PDF version with borked slide-notes in that directory if
  you can't read ODP.
 
  Chris -
  The PDF file is not world readable.
 
 It gets worse : it's not even a PDF.
 ;-)
 Coffee, Jeffrey.

André -
Perhaps you should get another cup.  Make it expresso.
Chris clearly states that there is *additionally* a PDF version, and that is 
the one that generates a permissions error.
The ODP version downloads just fine, though PowerPoint complains about errors, 
it seems OK (I still perusing).
I was trying to download the PDF version to use as a reference source for some 
of my less-technical staff.
Jeff

RE: Does the HeartBleed vulnerability affect Apache Tomcat servers using Tomcat Native?

[Jeffrey Janner]

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Wednesday, April 09, 2014 12:25 AM
 To: Tomcat Users List
 Subject: Re: Does the HeartBleed vulnerability affect Apache Tomcat
 servers using Tomcat Native?
 
 
 Arlo,
 
 On 4/8/14, 5:36 PM, Arlo White wrote:
  After updating OpenSSL I simply restarted Tomcat to eliminate the
  vulnerability.
 
 - -1
 
 You must re-key your server, and get a new cert from your CA. You have
 stopped the bleeding but your key should still be considered
 compromised.
 
  (Checked http://filippo.io/Heartbleed before and after) I built APR
  and Tomcat Native from source on the server, so I assume it's doing
  dynamic library loading.
 
  Is the binary build staticly linked? Otherwise, I'm not sure it's
  necessary to redo the builds.
 
 The ASF only provides binaries for win32, and yes, they are statically-
 linked. Users without the expertise to build their own tcnative binary
 will have to wait for the tcnative team to roll a new release.
 
 - -chris
Just to clarify what Chris is saying, ASF provides statically-linked binaries 
for Windows in zip files with the string win32 in the name.  The zip file 
actually contains versions for both x86 and x64 versions of Windows.
And yes, some of us don't have the expertise and/or tools to build the library 
ourselves under Windows.
Jeff

RE: Windows tcnative openssl ciphers question

[Jeffrey Janner]

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Tuesday, April 08, 2014 6:27 PM
 To: Tomcat Users List
 Subject: Re: Windows tcnative openssl ciphers question
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Jeffrey,
 
 On 4/7/14, 4:07 PM, Jeffrey Janner wrote:
  Ok, this is a question for the native libs builders (or whoever knows
  the answer). Environment:  Windows Server 2008 R2, Tomcat
  7.0.50 w/APR 1.1.29, Java 1.7.0_51  (all 64-bit) I'm trying to set up
  a ciphers list that will get me an A rating on Qualys' SSL testing
  tool.
 
 Did you read their guide? Certain factors limit your rating to B no
 matter what else happens. Lots of those factors are quite common in
 real-world deployments.
 
I actually managed to earn an A- rating, since I was only missing the ECDHE 
support to get Forward Secrecy to work on the IE browser family.
At least I had one until the Heartbleed bug raised its ugly head.  Now I'm back 
to F.

  I'm using the latest list suggested by MozillaWiki:
  ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-
 AE
  S256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-
 SHA25
  6:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-
 SHA256:ECDHE-
  ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-
 SHA:ECDHE-
  RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-
 SHA:ECDHE
  -ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-
 AES
  128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-
 SHA
  :AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-
 RC4
  -SHA:AES128:AES256:RC4-
 SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:
  !PSK
 
   However, when I run the test tool, it reports that the server is
 only
  supporting the following list:
  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
  TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
  TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256
  TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA
  TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA
  TLS_RSA_WITH_RC4_128_SHA TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
  TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
  TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
  TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
 
  Notice, none of the ECDHE-based ciphers are showing up in the list.
  This is apparently what is keeping me from getting that perfect
  score, as IE wants those ciphers for Forward Security.   It ends up
  taking one of the lower ciphers on the list. Does anyone know, is
  there a setting that needs to be made to enable those ciphers?
  Were they turned off in the dev stage?  Is it related to my
  certificate? Running the openssl.exe that comes with the APR binary
  download shows the ECDHE ciphers in the list. Any help appreciated.
 
 Did you set-up the Elliptic-curve parameters? If not, you can't use
 those ciphers.
 

Per someone (Mladen?) the capability wasn't enabled at build.
Last notice I received is he's addressing that in the next release.
Jeff

RE: How can I tell which version of OpenSSL is being used with tomcat?

[Jeffrey Janner]

 -Original Message-
 From: Andrew Russell [mailto:andrew.russ...@gmail.com]
 Sent: Wednesday, April 09, 2014 12:02 PM
 To: users@tomcat.apache.org
 Subject: How can I tell which version of OpenSSL is being used with
 tomcat?
 
 If I installed tomcat on windows using the service installer, how can I
 know which version of openssl was used?
[Jeff Janner] 

Did you select the Native Libraries when you ran the installer?
If so, you are most likely to be using OpenSSL for SSL services.
How can you be sure?
Do you have any Connectors set up to use SSL?  Did you specify the protocol 
parameter when you created the connector?  If not, then the default is to use 
the APR library if the Native Libraries are available and the APR Lifecycle 
Listener is in your server.xml and the SSLEngine is set to on.
In other words, you'll need to review your server.xml and the tomcat 
documentation on configuring Tomcat to see if you are vulnerable.

However, a perhaps easier way is to check your latest catalina.log file.  If it 
contains this line:
INFO: OpenSSL successfully initialized (OpenSSL 1.0.1e 11 Feb 2013)
Then you are susceptible (any version 1.0.1  1.0.1g).

Also, if you do have the native libraries in the bin directory, you can check 
its version by hovering over the tcnative-1.dll file and checking the value of 
File Version.  The latest is 1.1.29, which has the bug.  I'm not sure at which 
release the bug was introduced.
Anyone?


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

Temporary mitigation of Heartbleed?

[Jeffrey Janner]

Much as I loathe downgrading, would it be possible/advisable to downgrade the 
native libraries to 1.1.23 with Tomcat 7.0.50?
That version is the last to use a pre-1.0.1  version of OpenSSL (1.0.0g).
This could help us at least until we get a blessed version from the APR team?

Jeffrey Janner
Sr. Network Administrator
jeffrey.jan...@polydyne.commailto:first.l...@polydyne.com
PolyDyne Software Inc.
Main:   512.343.9100
Direct:  512.583.8930

 [cid:image002.png@01CC0FB7.4FF43CE0]

Speed, Intelligence  Savings in Sourcing

RE: Windows tcnative openssl ciphers question

[Jeffrey Janner]

 -Original Message-
 From: Ognjen Blagojevic [mailto:ognjen.d.blagoje...@gmail.com]
 Sent: Monday, April 07, 2014 5:27 PM
 To: Tomcat Users List
 Subject: Re: Windows tcnative openssl ciphers question
 
 Jeffrey,
 
 EECDH/ECDHE is disabled in tcnative-1.dll. There is already a request
 to enable it. Take a look at:
 
https://issues.apache.org/bugzilla/show_bug.cgi?id=55915
 
 -Ognjen
 
 
Thanks, thought that might have been the case, but was unsure, since the 
openssl lib that comes with it has it explicitly available.
Outside of downloading source and building myself, even if I knew what to do, 
appears to be the only way to enable it at the moment.

I'd like to urge all posters on here to please go vote for the bug.  It only 
has 1 vote at the moment.
Jeff

RE: Unable to start tomcat as a service.

[Jeffrey Janner]

 -Original Message-
 From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
 Sent: Tuesday, April 08, 2014 5:24 AM
 To: Tomcat Users List
 Subject: Re: Unable to start tomcat as a service.
 
 2014-04-08 13:42 GMT+04:00 akshay jain uniquejainaks...@gmail.com:
  Hi,
 
  I downloaded *apache-tomcat-7.0.52-windows-x64.zip* from the apache
  website.
  I am running windows 7 64 bit operating system.
 
  I have setup the file setenv.bat file and apache starts without any
  problem when started using startup.bat script.
 
  To run apache as a windows service I did the following steps:
  1. Extracted the zip to location C:\tmp 2. Opened command line in the
  said folder and ran command :
   tomcat7 //IS//
 
 That just installs procrun (the service wrapper executable), but DOES
 NOT configure it.
 Procrun with an empty configuration does not know what Java application
 it launches and with what settings. (It does not know that it belongs
 to Tomcat, etc.)
 
 There is service.bat that both installs and configures it, but note
 that you either need to run the command prompt in as administrator
 mode, or use 7.0.53 or later due to
 http://issues.apache.org/bugzilla/show_bug.cgi?id=56143
 
 
  3. Then ran command :
sc start tomcat7
 
  Following was the output :
 
  C:\tmp\apache-tomcat-7.0.52\bintomcat7.exe //IS//
 
  C:\tmp\apache-tomcat-7.0.52\binsc start tomcat7
 
  (...)
 
 
 Best regards,
 Konstantin Kolinko
 
You know, it still baffles me why folks still go this route on Windows when 
there's a perfectly good installer package that will take care of all the 
fiddly-bits for you. The only reason I can think of is they are trying to 
install on the GUI-less version of the Server OS, for which the service.bat 
file is a necessity.
Jeff


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

RE: How to monitor performance of tomcat

[Jeffrey Janner]

 -Original Message-
 From: Randhir Singh [mailto:randhir.si...@sterlite.com]
 Sent: Tuesday, April 08, 2014 6:05 AM
 To: users@tomcat.apache.org
 Subject: How to monitor performance of tomcat
 
 We have an application which has JBoss as the application server with
 Tomcat as the web server, our application has Oracle 11g as the
 database. I would give some further background to the issue we are
 facing, since the last 1 1/2 months, the application slows down.
 Sometimes it comes back to normal, specially on week-ends. But other
 times we restart JBoss  Tomcat to bring back the application to
 normal.
 
 
 
 We have been using jconsole to monitor tomcat like
 
 
 
 jconsole 10.101.17.79:8891
 
 
 
 which monitors our tomcat for a work order system. If the memory usage
 does not show spike and shows constant reading, the GC button is
 clicked to invoke the garbage collector.
 
 
 
 I checked out on the net and got some clue as below:
 
 
 
 1)  Javamelody - It seems to be a 3rd party tool which is not
 recommended.
 
 2)  There is a command mentioned to see the admin console,
 http://IP:port/ but it is not displaying the required page.
 
 
 
 Please give your inputs whether jconsole should be a help in the right
 direction or some other way to monitor the performance of Tomcat.
 
Jconsole and JVisualVm are quite useful tools for basic monitoring, if you 
understand how to use them and their limitations.
Why did you get the impression that JavaMelody is not recommended?  It does 
offer an awful lot of monitoring/debugging information, but you need to careful 
in setting it up.  Under Tomcat 7, it will autodeploy with no security by 
default and expose a lot of potentially confidential information to whomever 
connects using the well-known context for it (which can't be changed).  If 
you want to use it, I suggest limiting it to your development environment only, 
or reading up on how to secure it as best as possible.
Jeff



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

RE: Does the HeartBleed vulnerability affect Apache Tomcat servers using Tomcat Native?

[Jeffrey Janner]

Ognjen,
Has anyone entered a bugzilla request for this one?
Jeff

 -Original Message-
 From: Ognjen Blagojevic [mailto:ognjen.d.blagoje...@gmail.com]
 Sent: Tuesday, April 08, 2014 3:02 PM
 To: Tomcat Users List
 Subject: Re: Does the HeartBleed vulnerability affect Apache Tomcat
 servers using Tomcat Native?
 
 On 8.4.2014 18:48, Arlo White wrote:
  Are Apache Tomcat servers using Tomcat Native  APR vulnerable to the
  HeartBleed OpenSSL bug, or does this layer insulate them?
  http://heartbleed.com/
 
 They are vulnerable. There is no layer to insulate.
 
 You may test with:
 
http://filippo.io/Heartbleed/
 
 I tested with Tomcat 8.0.5 with tcnative 1.1.29, which includes OpenSSL
 1.0.1e, on Windows 7 64-bit, and it confirms the vulnerability.
 
 JSSE Connectors are not vulnerables so, one possible workaround is to
 swich to NIO or BIO connector until patched version of tcnative is
 available.
 
 -Ognjen
 
 -
 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: Does the HeartBleed vulnerability affect Apache Tomcat servers using Tomcat Native?

[Jeffrey Janner]

 -Original Message-
 From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
 Sent: Tuesday, April 08, 2014 5:14 PM
 To: 'Tomcat Users List'
 Subject: RE: Does the HeartBleed vulnerability affect Apache Tomcat
 servers using Tomcat Native?
 
 Ognjen,
 Has anyone entered a bugzilla request for this one?
 Jeff
 
Answering myself:
https://issues.apache.org/bugzilla/show_bug.cgi?id=56363
Might I suggest folks please go vote this one up big time!

RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

[Jeffrey Janner]

 -Original Message-
 From: David Kerber [mailto:dcker...@verizon.net]
 Sent: Saturday, April 05, 2014 5:57 AM
 To: Tomcat Users List
 Subject: Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
 not work
 
 ...
 
  but
  if the server is a *nix implementation, the better diag tool
  might be dig. And yes, I would not expect the address 0.0.0.0 on
  a client to connect to the localhost.  That is a special case
  address
  meaning
  local network. If anything, it would be sending packets out
 the
  NIC card, not via loopback.
  0.0.0.0 means all IPv4 interfaces available and only applies
 for
  binding a server socket. You can never connect to 0.0.0.0
  as a client.
 
  Chris - It actually has a different meaning based on use.  For
  binding to a socket in the local IP stack, it means what you say.
  In the routing table, it means the default route.  In
  firewalls/routers, it probably means something completely
  different. When used as a destination address, it means what I
  said.  How the IP stack/hardware deals with it is dependent on the
  implementation. The RFCs specify that it should be treated the
 same
  as the broadcast address, but local network only, and not
 routable.
  That may be for received packets only, as I've seen other
  references that it should never be used on-the-wire, unless as the
  source address in protocols like DHCP. In any event, definitely
 not
  expect the 0.0.0.0. address to get any response, either local host
  or otherwise. For the OP's specific problem, s/he need to see how
  localhost is resolving.  Most systems define it in the local
  hosts file, either /etc/hosts
  (*nix) or c:\Windows\system32\etc\hosts.  Not sure for other
  systems. Jeff
  Make that C:\Windows\system32\drivers\etc\hosts.
 
  I did a test and it appeared that ping didn't rely on the entry
  being there, but it could have been a cached result.
  Way back in the day when I had the misfortune to use Windows
  regularly for stuff like this, I seem to recall that almost nothing
  short of a reboot would cause the hosts file to be re-read.
 
  - -chris
 
 
  If I remember correctly, the Windows resolver cache may be cleared
  from a command prompt with ipconfig and that should include entries
  from the hosts file.  Seems like I may have had to restart the
 browser
  though to see any changes to the hosts file.
 
 ipconfig /flushdns
 

From empirical testing over the years, I'm pretty sure that Microsoft 
implements multiple levels of DNS caching.  I'm positive that the IE browser 
will cache some information on its own.  I've had DNS failures that would not 
resolve at the browser level after being fixed until I restarted the browser. 
I could resolve with nslookup, ping, etc., but the browser would still report 
an error.  Even the ipconfig /flushdns would not fix it for IE. If only the 
kids at MS would do things the correct and consistent way, life would be 
easier for all of us.
On my previously referenced test, I modified the hosts table to use 127.0.0.10 
for the localhost entry.  Ping picked it up right away, but reported results 
were from 127.0.0.1, which I'm sure was probably because of the initialized 
value pulled from the hosts table at boot.  Did not try, do not care, but it 
might have replied from the 10 address after a reboot. 
Note, I did not expect to see a change on an nslookup, since that tool is 
designed to query the DNS servers directly, bypassing the resolver.  It's a 
test tool for the DNS system, not the resolver sub-system.
This has gotten way of topic, so last word on my part.


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

Windows tcnative openssl ciphers question

[Jeffrey Janner]

Ok, this is a question for the native libs builders (or whoever knows the 
answer).
Environment:  Windows Server 2008 R2, Tomcat 7.0.50 w/APR 1.1.29, Java 1.7.0_51 
 (all 64-bit)
I'm trying to set up a ciphers list that will get me an A rating on Qualys' 
SSL testing tool.
I'm using the latest list suggested by MozillaWiki:
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK

However, when I run the test tool, it reports that the server is only 
supporting the following list:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA

Notice, none of the ECDHE-based ciphers are showing up in the list.  This is 
apparently what is keeping me from getting that perfect score, as IE wants 
those ciphers for Forward Security.   It ends up taking one of the lower 
ciphers on the list.
Does anyone know, is there a setting that needs to be made to enable those 
ciphers?  Were they turned off in the dev stage?  Is it related to my 
certificate?
Running the openssl.exe that comes with the APR binary download shows the ECDHE 
ciphers in the list.
Any help appreciated.

RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

[Jeffrey Janner]

 -Original Message-
 From: André Warnier [mailto:a...@ice-sa.com]
 Sent: Thursday, April 03, 2014 5:27 PM
 To: Tomcat Users List
 Subject: Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
 not work
 
 Christopher Schultz wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
 
  André,
 
  On 4/3/14, 3:34 PM, André Warnier wrote:
  Alten, Jessica-Aileen wrote:
  -Ursprüngliche Nachricht- Von: André Warnier
  [mailto:a...@ice-sa.com] Gesendet: Donnerstag, 3. April 2014
  15:36 An: Tomcat Users List Betreff: Re: AW:
  tomcat-connectors-1.2.39-windows-x86_64-iis does not work
 
  Alten, Jessica-Aileen wrote:
  A bit guessing here :
 
  You have :
  worker.ajp13w.host=localhost
  and
 
  jk_open_socket::jk_connect.c (735): connect to
  0.0.0.0:8009
  failed
  (errno=49)
  is localhost == 0.0.0.0  ?
 
  From the point of view of mod_jk/isapi, should it not be
  127.0.0.1 ?
  Your answer points to the right direction. 0.0.0.0 means: any
  configured IPv4-Address on this computer, see
 
  http://serverfault.com/questions/78048/whats-the-difference-
 betwee
  n-
  ip
  -addre ss-0-0-0-0-and-127-0-0-1
 
  In principle this is ok at first. The Ajp13 Connector was
  configured in server.xml to listen at any IPv4 address on port
  8009 - which is the default setting. But the connector can't find
  any suitable
  address.
  The problem is: The new Tomcat-Connector can't parse
  worker.ajp13w.host=localhost, instead localhost must be
 replaced
  with 127.0.0.1, this works!
 
  In my eyes this is a big fat bug, because most documentation on
  workers use localhost. localhost is actually the default for
 the
  host connection directive.
 
  The new worker directive prefer_ipv6 doesn't change this
  behavior.
 
  Hi.
 
  Can you please really check this ?
 
  Open a command window on that server, and do ping localhost.
  It should tell you what it understands by localhost. Copy and
  paste the result here :
  ping localhost
 
  Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit 32 Bytes
  Daten: Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von
  127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1:
  Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms
  TTL=128
 
  Ping-Statistik für 127.0.0.1: Pakete: Gesendet = 4, Empfangen = 4,
  Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.:
  Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms
 
 
  That /is/ bizarre.  As far as I know, to resolve hostnames in its
  configuration, mod_jk/isapi is using the OS's resolver library, the
  same as the one ping should be using. On the other hand, you say
  that if you have
 
  worker.ajp13w.host=localhost
  it doesn't work (mod_jk cannot connect to tomcat), but when you
  change this to
 
  worker.ajp13w.host=127.0.0.1
  then it works fine.
 
  Ok, another check in a command window (and I assume that you open
  this command window *on the server itself* where mod_jk and Tomcat
  are running, right ?)
 
  test :
 
  1) telnet localhost 8009
 
  2) telnet 127.0.0.1 8009
 
  Any difference between these 2 cases ?
 
  If not, then indeed it looks like a mod_jk/isapi_redirect 1.2.39
  problem.
 
  In any case, you cannot connect to 0.0.0.0, as this log line would
  suggest :
 
  jk_open_socket::jk_connect.c (735): connect to
  0.0.0.0:8009
  failed
 
  Could this be an interaction between IPv4 and IPv6? Try:
 
  C: nslookup localhost
 
  You might get only 127.0.0.1 or you might also get :: (or something
  equivalent). I'm not sure why it wasn't happening with earlier
  versions of mod_jk (which?).
 
 (versions : her first post mentioned the versions she was comparing)
 
 I previously asked Jessica-Aileen to do a ping localhost on the
 machine, see results above.  It definitiely pings 127.0.0.1 ..
 (assuming it was done on the same machine)
 
 And I don't think that nslookup uses the local resolver.
 When I'm doing that on my Windows laptop, for localhost it responds
 not found (in many more German words)
 
 C:\Dokumente und Einstellungen\awnslookup localhost
 Server:  fire-see.localdomain
 Address:  192.168.245.253
 
 *** localhost wurde von fire-see.localdomain nicht gefunden: Non-
 existent domain
 
 On the other hand, it does this (spot the difference..):
 
 C:\Dokumente und Einstellungen\awnslookup localhost.
 Server:  fire-see.localdomain
 Address:  192.168.245.253
 
 Name:localhost
 Address:  127.0.0.1
 
 (But that of course could be the localhost of my DNS server, since it
 happens to be a Linux box running dnsmasq, and it has that name in it's
 own hosts file.)
 
This result is understandable, as the nslookup tool is a DNS resolver tool.  
It's designed to query the DNS system directly, avoiding the systems resolver 
and any caching. Not exactly sure why it resolves localhost., but adding the 
final period tells it not to append the default domain.  In other words, 
localhost. Is a top-level domain.  Perhaps there is a special case built into 
the DNS system for 

RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

[Jeffrey Janner]

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Friday, April 04, 2014 10:23 AM
 To: Tomcat Users List
 Subject: Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
 not work
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Jeffrey,
 
 On 4/4/14, 10:50 AM, Jeffrey Janner wrote:
  -Original Message- From: André Warnier [mailto:aw@ice-
 sa.com]
  Sent: Thursday, April 03, 2014 5:27 PM To:
  Tomcat Users List Subject: Re: AW: AW:
  tomcat-connectors-1.2.39-windows-x86_64-iis does not work
 
  Christopher Schultz wrote:
  -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
  André,
 
  On 4/3/14, 3:34 PM, André Warnier wrote:
  Alten, Jessica-Aileen wrote:
  -Ursprüngliche Nachricht- Von: André Warnier
  [mailto:a...@ice-sa.com] Gesendet: Donnerstag, 3. April
  2014 15:36 An: Tomcat Users List Betreff: Re: AW:
  tomcat-connectors-1.2.39-windows-x86_64-iis does not work
 
  Alten, Jessica-Aileen wrote:
  A bit guessing here :
 
  You have :
  worker.ajp13w.host=localhost
  and
 
  jk_open_socket::jk_connect.c (735): connect to
  0.0.0.0:8009
  failed
  (errno=49)
  is localhost == 0.0.0.0  ?
 
  From the point of view of mod_jk/isapi, should it not be
  127.0.0.1 ?
  Your answer points to the right direction. 0.0.0.0
  means: any configured IPv4-Address on this computer, see
 
  http://serverfault.com/questions/78048/whats-the-difference-
 
 
 betwee
  n-
  ip
  -addre ss-0-0-0-0-and-127-0-0-1
 
  In principle this is ok at first. The Ajp13 Connector was
  configured in server.xml to listen at any IPv4 address on port
  8009 - which is the default setting.
  But the connector can't find any suitable
  address.
  The problem is: The new Tomcat-Connector can't parse
  worker.ajp13w.host=localhost, instead localhost must be
  replaced
  with 127.0.0.1, this works!
 
  In my eyes this is a big fat bug, because most documentation on
  workers use localhost. localhost is actually the default for
  the
  host connection directive.
 
  The new worker directive prefer_ipv6 doesn't change this
  behavior.
 
  Hi.
 
  Can you please really check this ?
 
  Open a command window on that server, and do ping localhost.
 It
  should tell you what it understands by localhost. Copy and
  paste the result here :
  ping localhost
 
  Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit 32 Bytes
  Daten: Antwort von 127.0.0.1: Bytes=32 Zeit1ms
  TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort
  von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1:
  Bytes=32 Zeit1ms TTL=128
 
  Ping-Statistik für 127.0.0.1: Pakete: Gesendet = 4, Empfangen =
 4,
  Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum
 =
  0ms, Maximum = 0ms, Mittelwert = 0ms
 
 
  That /is/ bizarre.  As far as I know, to resolve hostnames in its
  configuration, mod_jk/isapi is using the OS's resolver library,
 the
  same as the one ping should be using. On the other hand, you say
  that if you have
 
  worker.ajp13w.host=localhost
  it doesn't work (mod_jk cannot connect to tomcat), but when you
  change this to
 
  worker.ajp13w.host=127.0.0.1
  then it works fine.
 
  Ok, another check in a command window (and I assume that you open
  this command window *on the server itself* where mod_jk and Tomcat
  are running, right ?)
 
  test :
 
  1) telnet localhost 8009
 
  2) telnet 127.0.0.1 8009
 
  Any difference between these 2 cases ?
 
  If not, then indeed it looks like a mod_jk/isapi_redirect
  1.2.39 problem.
 
  In any case, you cannot connect to 0.0.0.0, as this log line
  would suggest :
 
  jk_open_socket::jk_connect.c (735): connect to
  0.0.0.0:8009
  failed
 
  Could this be an interaction between IPv4 and IPv6? Try:
 
  C: nslookup localhost
 
  You might get only 127.0.0.1 or you might also get :: (or something
  equivalent). I'm not sure why it wasn't happening with earlier
  versions of mod_jk (which?).
 
  (versions : her first post mentioned the versions she was
  comparing)
 
  I previously asked Jessica-Aileen to do a ping localhost on the
  machine, see results above.  It definitiely pings 127.0.0.1 ..
  (assuming it was done on the same machine)
 
  And I don't think that nslookup uses the local resolver. When I'm
  doing that on my Windows laptop, for localhost it responds not
  found (in many more German words)
 
  C:\Dokumente und Einstellungen\awnslookup localhost Server:
  fire-see.localdomain Address:  192.168.245.253
 
  *** localhost wurde von fire-see.localdomain nicht gefunden:
  Non- existent domain
 
  On the other hand, it does this (spot the difference..):
 
  C:\Dokumente und Einstellungen\awnslookup localhost. Server:
  fire-see.localdomain Address:  192.168.245.253
 
  Name:localhost Address:  127.0.0.1
 
  (But that of course could be the localhost of my DNS server, since
  it happens to be a Linux box running dnsmasq, and it has that name
 in
  it's own hosts file.)
 
  This result is understandable

RE: [OT] AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

[Jeffrey Janner]

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Friday, April 04, 2014 10:20 AM
 To: Tomcat Users List
 Subject: Re: [OT] AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis
 does not work
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Jeffrey,
 
 On 4/4/14, 10:50 AM, Jeffrey Janner wrote:
  I've not followed the complete thread, but if the server is a *nix
  implementation, the better diag tool might be dig.
 
 No, you haven't been following it well. The subject pretty much rules-
 out a *NIX environment ;)
 
Touché


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

RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

[Jeffrey Janner]

 -Original Message-
 From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
 Sent: Friday, April 04, 2014 12:04 PM
 To: 'Tomcat Users List'
 Subject: RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
 not work
 
  -Original Message-
  From: Christopher Schultz [mailto:ch...@christopherschultz.net]
  Sent: Friday, April 04, 2014 10:23 AM
  To: Tomcat Users List
  Subject: Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
  not work
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
 
  Jeffrey,
 
  On 4/4/14, 10:50 AM, Jeffrey Janner wrote:
   -Original Message- From: André Warnier [mailto:aw@ice-
  sa.com]
   Sent: Thursday, April 03, 2014 5:27 PM To:
   Tomcat Users List Subject: Re: AW: AW:
   tomcat-connectors-1.2.39-windows-x86_64-iis does not work
  
   Christopher Schultz wrote:
   -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
  
   André,
  
   On 4/3/14, 3:34 PM, André Warnier wrote:
   Alten, Jessica-Aileen wrote:
   -Ursprüngliche Nachricht- Von: André Warnier
   [mailto:a...@ice-sa.com] Gesendet: Donnerstag, 3. April
   2014 15:36 An: Tomcat Users List Betreff: Re: AW:
   tomcat-connectors-1.2.39-windows-x86_64-iis does not work
  
   Alten, Jessica-Aileen wrote:
   A bit guessing here :
  
   You have :
   worker.ajp13w.host=localhost
   and
  
   jk_open_socket::jk_connect.c (735): connect to
   0.0.0.0:8009
   failed
   (errno=49)
   is localhost == 0.0.0.0  ?
  
   From the point of view of mod_jk/isapi, should it not be
   127.0.0.1 ?
   Your answer points to the right direction. 0.0.0.0
   means: any configured IPv4-Address on this computer, see
  
   http://serverfault.com/questions/78048/whats-the-difference-
  
  
  betwee
   n-
   ip
   -addre ss-0-0-0-0-and-127-0-0-1
  
   In principle this is ok at first. The Ajp13 Connector was
   configured in server.xml to listen at any IPv4 address on
 port
   8009 - which is the default setting.
   But the connector can't find any suitable
   address.
   The problem is: The new Tomcat-Connector can't parse
   worker.ajp13w.host=localhost, instead localhost must be
   replaced
   with 127.0.0.1, this works!
  
   In my eyes this is a big fat bug, because most documentation
   on workers use localhost. localhost is actually the default
   for
   the
   host connection directive.
  
   The new worker directive prefer_ipv6 doesn't change this
   behavior.
  
   Hi.
  
   Can you please really check this ?
  
   Open a command window on that server, and do ping localhost.
  It
   should tell you what it understands by localhost. Copy and
   paste the result here :
   ping localhost
  
   Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit 32 Bytes
   Daten: Antwort von 127.0.0.1: Bytes=32 Zeit1ms
   TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128
 Antwort
   von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von 127.0.0.1:
   Bytes=32 Zeit1ms TTL=128
  
   Ping-Statistik für 127.0.0.1: Pakete: Gesendet = 4, Empfangen =
  4,
   Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.:
 Minimum
  =
   0ms, Maximum = 0ms, Mittelwert = 0ms
  
  
   That /is/ bizarre.  As far as I know, to resolve hostnames in
 its
   configuration, mod_jk/isapi is using the OS's resolver library,
  the
   same as the one ping should be using. On the other hand, you
   say that if you have
  
   worker.ajp13w.host=localhost
   it doesn't work (mod_jk cannot connect to tomcat), but when you
   change this to
  
   worker.ajp13w.host=127.0.0.1
   then it works fine.
  
   Ok, another check in a command window (and I assume that you
 open
   this command window *on the server itself* where mod_jk and
   Tomcat are running, right ?)
  
   test :
  
   1) telnet localhost 8009
  
   2) telnet 127.0.0.1 8009
  
   Any difference between these 2 cases ?
  
   If not, then indeed it looks like a mod_jk/isapi_redirect
   1.2.39 problem.
  
   In any case, you cannot connect to 0.0.0.0, as this log line
   would suggest :
  
   jk_open_socket::jk_connect.c (735): connect to
   0.0.0.0:8009
   failed
  
   Could this be an interaction between IPv4 and IPv6? Try:
  
   C: nslookup localhost
  
   You might get only 127.0.0.1 or you might also get :: (or
   something equivalent). I'm not sure why it wasn't happening with
   earlier versions of mod_jk (which?).
  
   (versions : her first post mentioned the versions she was
   comparing)
  
   I previously asked Jessica-Aileen to do a ping localhost on the
   machine, see results above.  It definitiely pings 127.0.0.1 ..
   (assuming it was done on the same machine)
  
   And I don't think that nslookup uses the local resolver. When I'm
   doing that on my Windows laptop, for localhost it responds not
   found (in many more German words)
  
   C:\Dokumente und Einstellungen\awnslookup localhost Server:
   fire-see.localdomain Address:  192.168.245.253
  
   *** localhost wurde von fire-see.localdomain nicht gefunden:
   Non- existent domain
  
   On the other hand

RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

[Jeffrey Janner]

 -Original Message-
 From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
 Sent: Friday, April 04, 2014 12:10 PM
 To: 'Tomcat Users List'
 Subject: RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
 not work
 
  -Original Message-
  From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
  Sent: Friday, April 04, 2014 12:04 PM
  To: 'Tomcat Users List'
  Subject: RE: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does
  not work
 
   -Original Message-
   From: Christopher Schultz [mailto:ch...@christopherschultz.net]
   Sent: Friday, April 04, 2014 10:23 AM
   To: Tomcat Users List
   Subject: Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis
   does not work
  
   -BEGIN PGP SIGNED MESSAGE-
   Hash: SHA256
  
   Jeffrey,
  
   On 4/4/14, 10:50 AM, Jeffrey Janner wrote:
-Original Message- From: André Warnier [mailto:aw@ice-
   sa.com]
Sent: Thursday, April 03, 2014 5:27 PM To:
Tomcat Users List Subject: Re: AW: AW:
tomcat-connectors-1.2.39-windows-x86_64-iis does not work
   
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
   
André,
   
On 4/3/14, 3:34 PM, André Warnier wrote:
Alten, Jessica-Aileen wrote:
-Ursprüngliche Nachricht- Von: André Warnier
[mailto:a...@ice-sa.com] Gesendet: Donnerstag, 3. April
2014 15:36 An: Tomcat Users List Betreff: Re: AW:
tomcat-connectors-1.2.39-windows-x86_64-iis does not work
   
Alten, Jessica-Aileen wrote:
A bit guessing here :
   
You have :
worker.ajp13w.host=localhost
and
   
jk_open_socket::jk_connect.c (735): connect to
0.0.0.0:8009
failed
(errno=49)
is localhost == 0.0.0.0  ?
   
From the point of view of mod_jk/isapi, should it not be
127.0.0.1 ?
Your answer points to the right direction. 0.0.0.0
means: any configured IPv4-Address on this computer, see
   
http://serverfault.com/questions/78048/whats-the-
 difference-
   
   
   betwee
n-
ip
-addre ss-0-0-0-0-and-127-0-0-1
   
In principle this is ok at first. The Ajp13 Connector was
configured in server.xml to listen at any IPv4 address on
  port
8009 - which is the default setting.
But the connector can't find any suitable
address.
The problem is: The new Tomcat-Connector can't parse
worker.ajp13w.host=localhost, instead localhost must be
replaced
with 127.0.0.1, this works!
   
In my eyes this is a big fat bug, because most
 documentation
on workers use localhost. localhost is actually the
default for
the
host connection directive.
   
The new worker directive prefer_ipv6 doesn't change this
behavior.
   
Hi.
   
Can you please really check this ?
   
Open a command window on that server, and do ping
 localhost.
   It
should tell you what it understands by localhost. Copy and
paste the result here :
ping localhost
   
Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit 32
 Bytes
Daten: Antwort von 127.0.0.1: Bytes=32 Zeit1ms
TTL=128 Antwort von 127.0.0.1: Bytes=32 Zeit1ms TTL=128
  Antwort
von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von
 127.0.0.1:
Bytes=32 Zeit1ms TTL=128
   
Ping-Statistik für 127.0.0.1: Pakete: Gesendet = 4, Empfangen
=
   4,
Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.:
  Minimum
   =
0ms, Maximum = 0ms, Mittelwert = 0ms
   
   
That /is/ bizarre.  As far as I know, to resolve hostnames in
  its
configuration, mod_jk/isapi is using the OS's resolver
 library,
   the
same as the one ping should be using. On the other hand, you
say that if you have
   
worker.ajp13w.host=localhost
it doesn't work (mod_jk cannot connect to tomcat), but when
 you
change this to
   
worker.ajp13w.host=127.0.0.1
then it works fine.
   
Ok, another check in a command window (and I assume that you
  open
this command window *on the server itself* where mod_jk and
Tomcat are running, right ?)
   
test :
   
1) telnet localhost 8009
   
2) telnet 127.0.0.1 8009
   
Any difference between these 2 cases ?
   
If not, then indeed it looks like a mod_jk/isapi_redirect
1.2.39 problem.
   
In any case, you cannot connect to 0.0.0.0, as this log line
would suggest :
   
jk_open_socket::jk_connect.c (735): connect to
0.0.0.0:8009
failed
   
Could this be an interaction between IPv4 and IPv6? Try:
   
C: nslookup localhost
   
You might get only 127.0.0.1 or you might also get :: (or
something equivalent). I'm not sure why it wasn't happening
 with
earlier versions of mod_jk (which?).
   
(versions : her first post mentioned the versions she was
comparing)
   
I previously asked Jessica-Aileen to do a ping localhost on
 the
machine, see results above.  It definitiely pings 127.0.0.1 ..
(assuming it was done on the same machine

RE: Need urgent help - Removing jvmoptions from tomcat service

[Jeffrey Janner]

 -Original Message-
 From: Mukul Bhatnagar [mailto:mukul@gmail.com]
 Sent: Monday, March 31, 2014 12:40 PM
 To: users@tomcat.apache.org
 Subject: Fwd: Need urgent help - Removing jvmoptions from tomcat
 service
 
 -- Forwarded message --
 From: Mukul Bhatnagar mukul@gmail.com
 Date: Mon, Mar 31, 2014 at 10:59 PM
 Subject: Need urgent help - Removing jvmoptions from tomcat service
 To: users-h...@tomcat.apache.org
 
 
 Hi all,
 
 I am using tomcat as Windows service for my application. I created JVM
 options. lets say -Djava.library some path.
 Now everything runs fine and i do see the java properties using the
 command
 line:
 
 tomcat7w.exe //ES//applId
 
 Now, since everything i am doing is in batch script.When i am
 uninstalling the service, the JVMoptions donot get deleted. they stay
 there forever and on installing/executing the service, the JVMoptions
 get duplicated.
 
 how do i remove JVMoptions in my script during uninstalltion of tomcat
 service, what is the command line for that?
 
 --
 Warm Regards,
 Mukul Bhatnagar
 

How are you installing/uninstalling the service/options?
Normally, the recommending way of working with the windows service runner (aka 
Apache Commons Daemon) will uninstall any added/changed options.
Perhaps reading the documentation on ACD will give you some insight.


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

RE: Scripting Tomcat installation versus multiple instances

[Jeffrey Janner]

 -Original Message-
 From: David kerber [mailto:dcker...@verizon.net]
 Sent: Wednesday, March 26, 2014 2:35 PM
 To: Tomcat Users List
 Subject: Re: Scripting Tomcat installation versus multiple instances
 
 On 3/26/2014 3:25 PM, André Warnier wrote:
  Leo Donahue wrote:
  On Wed, Mar 26, 2014 at 11:32 AM, Sebastien Tardif 
  sebastien.tardif.contrac...@gmo.com wrote:
 
  I'm confused by the commands given by Tomcat documentation about
  creating different instances, it says: service install instance1
  but service is not a command provided by Tomcat or Windows, see
  http://tomcat.apache.org/tomcat-7.0-doc/windows-service-
 howto.html#M
  ultiple_Instances
 
 
  Almost everything I'm trying to automate using that page is not
  working, maybe it's rare people automate installation on Windows?
 
 
  The service command is located here:  \apache-tomcat-7.0.52\bin
 
  change directories to this location and run that command.
 
 
  Maybe also the OP did not download the correct package to have that
  command.
  For some reason which is still mysterious to me, the Service
 Installer
  package does not contain all the files which the ZIP package
 contains.
  And bin/service.bat is probably among the ones missing.
 
 Yes, it is.  When I am setting up a new install, I do the windows
 install and then unzip the .zip package on top of it, so I have all the
 .bat files as well.  I don't fully automate my installations, but I do
 some scripting to make it easier to be consistent with my naming and
 configuration.
 

I've found with the Windows service installer that I've never needed the *.bat 
files that come with the zip file.
However, one thing I'm not sure about is if the WSI has a -silent mode.  It 
would be great if it did.  It really would help out in scripting the install as 
part of another install, etc.


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

RE: Site down for maintenance senario

[Jeffrey Janner]

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Thursday, March 13, 2014 10:40 AM
 To: Tomcat Users List
 Subject: Re: Site down for maintenance senario
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 John,
 
 On 3/12/14, 2:28 PM, John Smith wrote:
  Is there a straightforward way to toggle or add something in Tomcat,
  in the event a webapp is intentionally taken 'offline for
  maintenance? The user would receive the same single notification
 page
  saying as much, for any and all requests.
 
  Tomcat 7.0.42
 
 Deploy a ROOT web application whose 404 page says Down for
 maintenance. You could even customize this kind of thing to only
 respond to certain URL-prefixes (like [ROOT]/mywebapp/*).
 
 What will you do while Tomcat is restarting, though, if you have to
 restart?
 

This kind of requirement is where fronting with HTTPD comes in handy.
Of course, if you're restarting HTTPD, you still won't get an error message.

RE: The Service Component

[Jeffrey Janner]

 -Original Message-
 From: Leo Donahue [mailto:donahu...@gmail.com]
 Sent: Monday, March 10, 2014 4:21 PM
 To: Tomcat Users List
 Subject: Re: The Service Component
 
 On Mon, Mar 10, 2014 at 7:26 AM, Jeffrey Janner
 jeffrey.jan...@polydyne.com
  wrote:
 
   -Original Message-
   From: Leo Donahue [mailto:donahu...@gmail.com]
   Sent: Friday, March 07, 2014 9:44 AM
   To: users@tomcat.apache.org
   Subject: The Service Component
  
   Who uses more than one Service in their server.xml and why?  I get
   that you can have multiple Connectors if you have multiple Service
   components but why use multiple connectors?
  
   Are there any docs on the use cases for these features?
  
 
  Hi Leo,
  I may be the only person on this list who does this consistently.
  I use it as an alternative method of virtual hosting, i.e. each host
  gets its own Service and related sub-structure.
 
 
 You are lucky you have control over that.  I have no luck asking our
 data center to add another host entry to our web server.  I always ask
 them, isn't it easier than asking you for another vm?  :)
And it wastes a hellofalot fewer resources.


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

RE: simple way to access application in multi instance envirnoment

[Jeffrey Janner]

 -Original Message-
 From: Ahmed Dalatony [mailto:ahmed.dalat...@gmail.com]
 Sent: Sunday, March 09, 2014 2:16 PM
 To: Tomcat Users List
 Subject: Re: simple way to access application in multi instance
 envirnoment
 
 On Sun, Mar 9, 2014 at 7:48 PM, Neven Cvetkovic
 neven.cvetko...@gmail.comwrote:
 
  On Sun, Mar 9, 2014 at 11:29 AM, Ahmed Dalatony
  ahmed.dalat...@gmail.com
  wrote:
 
   On Sun, Mar 9, 2014 at 5:05 PM, Neven Cvetkovic
   neven.cvetko...@gmail.comwrote:
  
Ahmed,
   
On Sun, Mar 9, 2014 at 10:14 AM, Ahmed Dalatony 
   ahmed.dalat...@gmail.com
wrote:
   
 hello,

can you help me little more with example or simpler doc
 i'm new to tomcat config
 and i don't understand virtual host

 thank you
  
  
  What environment do you use?  e.g. Windows, Linux, etc.
  If Linux, what flavour of Linux? e.g. RHEL (CentOS, Fedora), Ubuntu,
 etc.
  What webserver would you like to use? e.g. Apache HTTPD, IIS, nginx,
 etc.
 
  They all have different ways to configure your setup.
 
  - The easier one to setup is to use mod_proxy, check examples here:
  https://tomcat.apache.org/tomcat-7.0-doc/proxy-howto.html
 
  - More common is to use AJP protocol and mod_jk in Apache, check
  examples
  here:
  http://tomcat.apache.org/connectors-doc/generic_howto/quick.html
  http://tomcat.apache.org/connectors-doc/reference/apache.html
 
  Hope that helps.
  n.
 
 
 hello,
 I'm using win server 2008 running a combination of tomcat 6, tomcat 7,
 oc4j 10g on different ports the resources you supplied are very handy
 but they explain accessing http://www.myhost.com:/App1   from
 http://www.myhost.com/App1
 is it applicable to be accessed from URL like this
 http://App1.myhost.com
 
 thanks,
If you really want the last URL style, http://app.mydomain.com/, then you can 
do it with any of the alternatives Neven mentioned, except Alt_0. 
For Alt_1 and Alt_2, once you set up the Host tags, you set up each App as 
the ROOT context.  Hint: It's best to view this as setting up a single host to 
do one app as ROOT, and then just apply it to multiple Hosts.
For Alt_2, you can assign multiple IPs to a single network interface in 
Windows, in case you have a limited number of physical ports.
With your explanation of your current setup, I'd say you'd want either Alt_2 or 
Alt_3.  For Alt_2, it's just reconfiguring your server.xml files to specify the 
address= parameter on the Connector tag, and set the port to 80, with each 
Tomcat getting a unique IP.
Alt_3 can be accomplished without modifying your current Tomcats, or not 
modifying them by much, and offers a little more flexibility, but you have a 
learning curve ahead of you on configuring the Apache HTTPd server 
appropriately.  However, it would give you the option of adding additional 
Tomcats for an app with the httpd server acting as a load balancer if you find 
you need additional capacity for that one app.
Of course, don't forget the DNS mapping of the new hostnames to IP addresses.
I do this all the time in my environment, and actually have servers setup in a 
combined Alt_1  Alt_2 environment. That is, multiple Tomcat instances, some 
dedicated to a specific host, some using virtual hosting, all on the same 
server.
Jeff


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

RE: The Service Component

[Jeffrey Janner]

 -Original Message-
 From: Leo Donahue [mailto:donahu...@gmail.com]
 Sent: Friday, March 07, 2014 9:44 AM
 To: users@tomcat.apache.org
 Subject: The Service Component
 
 Who uses more than one Service in their server.xml and why?  I get that
 you can have multiple Connectors if you have multiple Service
 components but why use multiple connectors?
 
 Are there any docs on the use cases for these features?
 

Hi Leo,
I may be the only person on this list who does this consistently.
I use it as an alternative method of virtual hosting, i.e. each host gets its 
own Service and related sub-structure.
The real reason?  The default host has to be set to something, and I don't want 
to maintain some generic host to catch those that come in.  Since I'm running 
an SaaS environment, really more ASP, a business requirement is that each host 
appear to the outside world as a unique physical host, so two customers don't 
get the same IP address. I could add Alias tags for the IP address and all 
know variations of the hostname, but there's nothing to keep some yahoo admin 
at a customer site from configuring a DNS entry on an internal DNS server with 
some name I'm not expecting.  Therefore, each Engine in each Service gets a 
defaultHost entry pointing to its one and only Host entry.
As an added benefit, if I find I need to move a customer from a shared Tomcat 
setup to a unique Tomcat, all I need to do is set up a new blank Tomcat and 
move the Service structure from one Tomcat to another. Naturally, there's 
more work needed if I find I need to give them their own physical server, but 
that's to be expected.  In general, not counting any hardware setup, I can move 
a host to another tomcat instance with  2 minutes downtime.
Jeff 


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

RE: Tomcat7w.exe

[Jeffrey Janner]

 -Original Message-
 From: Leo Donahue [mailto:donahu...@gmail.com]
 Sent: Friday, March 07, 2014 11:10 AM
 To: users@tomcat.apache.org
 Subject: Tomcat7w.exe
 
 Did I miss something in the documentation about renaming this if one is
 running multiple windows services of Tomcat?
 
 ex:
 #Prod port 80
 c:\apache-tomcat
 c:\apache-tomcat\apache-tomcat-7.0.52
 service install Tomcat7 (from bin directory here)
 
 #Dev port 8080
 c:\apache-tomcat-dev
 c:\apache-tomcat-dev\apache-tomcat-7.0.52
 service install Tomcat7dev (from bin directory here)
 
 If I run the Tomcat7w.exe from #Dev, all of those settings point to
 #Prod.
 
 Unless I change the name of Tomcat7w.exe in #Dev to Tomcat7devw.exe,
 then everything is fine.
 
 Was that listed in the docs somewhere and I missed it?

Leo, 
If you use the Windows installer that the foundation thoughtfully provides, 
you'll see that the installer actually renames the executables to whatever you 
put in the Windows Service Name field.  So, if you use it to install one 
instance with the service name Prod, then in the bin directory, you will have 
Prod.exe and Prodw.exe.  If you second instance uses the service name Dev, 
then the bin directory will have Dev.exe and Devw.exe.  And when you go to look 
for those processes using Task Manager, or Process Explorer, or whatever tool 
you use, they will actually show up as those names.  No more trying to figure 
out which Tomcat.exe is which.
Jeff


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

RE: The Service Component

[Jeffrey Janner]

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Monday, March 10, 2014 10:15 AM
 To: Tomcat Users List
 Subject: Re: The Service Component
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Jeffrey,
 
 On 3/10/14, 10:26 AM, Jeffrey Janner wrote:
  -Original Message- From: Leo Donahue
  [mailto:donahu...@gmail.com] Sent: Friday, March 07, 2014 9:44 AM
 To:
  users@tomcat.apache.org Subject: The Service Component
 
  Who uses more than one Service in their server.xml and why?  I get
  that you can have multiple Connectors if you have multiple Service
  components but why use multiple connectors?
 
  Are there any docs on the use cases for these features?
 
 
  Hi Leo, I may be the only person on this list who does this
  consistently. I use it as an alternative method of virtual hosting,
  i.e. each host gets its own Service and related sub-structure.
  The real reason?  The default host has to be set to something, and I
  don't want to maintain some generic host to catch those that come in.
  Since I'm running an SaaS environment, really more ASP, a business
  requirement is that each host appear to the outside world as a unique
  physical host, so two customers don't get the same IP address. I
 could
  add Alias tags for the IP address and all know variations of the
  hostname, but there's nothing to keep some yahoo admin at a customer
  site from configuring a DNS entry on an internal DNS server with some
  name I'm not expecting.  Therefore, each Engine in each Service
  gets a defaultHost entry pointing to its one and only Host entry.
 
 I'm interested in this use case.
 
 Since you have to maintain a Connector for every IP address already,
 how is that different from having a single Connector with a bunch of
 Alias elements? How are those different? Or is it that you need
 application isolation in the first place, so this is the best way to do
 it in a single JVM?
 

It's primarily for App Isolation. 
The other is that I'm trying to keep the modifiable elements to a minimum, so 
that someone not completely versed in Tomcat can do a setup if I'm not 
available.
Essentially, I have a predefined with Service tree that can be copied to a 
server.xml and only need to modify 7 values, 2 IP address fields, and 2 
hostname fields, and engine name, a service name, and an appbase.  The way I 
have it setup right now, you enter the same value for the last 3 entries in 
that list to make it easy to manage at the file system level.
And by keeping it compact, it makes that move I mentioned easy, since all the 
elements are together in the server.xml (as opposed to Connectors being in 
one location and Hosts in another.
Jeff

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

RE: ApacheCon North America, Denver, April 7-11

[Jeffrey Janner]

 -Original Message-
 From: Rich Bowen [mailto:rbo...@rcbowen.com]
 Sent: Tuesday, March 04, 2014 2:59 PM
 To: d...@tomcat.apache.org; users@tomcat.apache.org
 Subject: ApacheCon North America, Denver, April 7-11
 
 Hello Tomcat enthusiasts,
 
 as you are no doubt aware, ApacheCon North America will be held in
 Denver, Colorado starting on April 7th. Tomcat will be represented
 there by a full day of content in the following talks:
 http://apacheconnorthamerica2014.sched.org/overview/type/tomcat
 
 We would love to see you in Denver next month. Register soon, as prices
 go up on March 14th. http://na.apachecon.com/
 
 --
 Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ -
 @apachecon

Is it really April 7-11 or 7-9 as stated on the website homepage?



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

RE: The Service Component

[Jeffrey Janner]

 -Original Message-
 From: André Warnier [mailto:a...@ice-sa.com]
 Sent: Monday, March 10, 2014 12:15 PM
 To: Tomcat Users List
 Subject: Re: The Service Component
 
 Christopher Schultz wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
 
  Jeffrey,
 
  On 3/10/14, 10:26 AM, Jeffrey Janner wrote:
  -Original Message- From: Leo Donahue
  [mailto:donahu...@gmail.com] Sent: Friday, March 07, 2014 9:44 AM
  To: users@tomcat.apache.org Subject: The Service Component
 
  Who uses more than one Service in their server.xml and why?  I get
  that you can have multiple Connectors if you have multiple Service
  components but why use multiple connectors?
 
  Are there any docs on the use cases for these features?
 
  Hi Leo, I may be the only person on this list who does this
  consistently. I use it as an alternative method of virtual hosting,
  i.e. each host gets its own Service and related sub-structure.
  The real reason?  The default host has to be set to something, and I
  don't want to maintain some generic host to catch those that come
 in.
  Since I'm running an SaaS environment, really more ASP, a business
  requirement is that each host appear to the outside world as a
 unique
  physical host, so two customers don't get the same IP address. I
  could add Alias tags for the IP address and all know variations of
  the hostname, but there's nothing to keep some yahoo admin at a
  customer site from configuring a DNS entry on an internal DNS server
  with some name I'm not expecting.  Therefore, each Engine in each
  Service gets a defaultHost entry pointing to its one and only
  Host entry.
 
  I'm interested in this use case.
 
  Since you have to maintain a Connector for every IP address
 already,
  how is that different from having a single Connector with a bunch
 of
  Alias elements? How are those different? Or is it that you need
  application isolation in the first place, so this is the best way to
  do it in a single JVM?
 
  As an added benefit, if I find I need to move a customer from a
  shared Tomcat setup to a unique Tomcat, all I need to do is set up a
  new blank Tomcat and move the Service structure from one Tomcat to
  another. Naturally, there's more work needed if I find I need to
 give
  them their own physical server, but that's to be expected.  In
  general, not counting any hardware setup, I can move a host to
  another tomcat instance with  2 minutes downtime.
 
  Nice.
 
 
 It is particularly nice to know that it works, and that the Service
 element really
 (apparently) corresponds to something real at the Tomcat level.  So
 it is apparently not just an element of order allowing to group
 Connectors with Engine.
 Which is contrary to what I imagined, and which I believe definitely
 answers the original OP's question (at least the first part).
 
 And I believe it is worth repeating what was already mentioned earlier
 regarding the Service/Connector relationship :
 Even if you have only one Service, you can have multiple
 Connector's inside it, and there are plenty of use cases for that.
 And if you have multiple Service's, you can also have more than 1
 Connector per Service, but each Connector (even across
 Service's) will still need its own unique listening IP address:Port
 combination.
 
 As to running multiple Service's within the same Tomcat instance, as
 opposed to running multiple single-Service Tomcat instances : in the
 multiple-Service scenario, they all share the same JVM, the same
 Heap, the same Stack etc.  So if you bring one Service
 down, they all go down.
 Which is not the case for multiple Tomcat instances.

True, if you crash the JVM, everything goes away, but that's true for any 
virtual hosting setup with multiple hosts/Tomcat.
However, I have had an app hang and which caused its connector's queue to fill 
and thus appearing to crash, yet the other services were happily chugging 
away in the JVM.
(Yep, they got moved to their own Tomcat instance until the problem was 
corrected.)

RE: Executor thread pool

[Jeffrey Janner]

 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Monday, March 10, 2014 11:22 AM
 To: Tomcat Users List
 Subject: Re: Executor thread pool
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 John,
 
 On 3/10/14, 11:43 AM, John Smith wrote:
  How dumb am I being by not using an Executor with a named thread
 pool?
  Currently I just have a Connector in server.xml:
 
  Connector port=8080
  protocol=org.apache.coyote.http11.Http11NioProtocol
  connectionTimeout=2 redirectPort=8443 /
 
 An executor is being used under the covers... you just aren't
 configuring it yourself.
 
 If you don't configure it yourself you lose out on these benefits:
 
 1. Shared executor for multiple Connectors. If you only have a single
 connector, obviously this matters little.
 
 2. You have less control over the underlying Executor if you don't
 manually configure it and let the Connector auto-create one. Check the
 documentation for http://tomcat.apache.org/tomcat-7.0-
 doc/config/executor.html against the thread-related configuration
 attributes available for, say, the HTTP connector here
 http://tomcat.apache.org/tomcat-7.0-doc/config/http.html and you'll see
 what I mean.
 
  Assuming ~2000 simultaneous connections. Tomcat 7.0.42. RHEL6.
 
 2000 simultaneous connections really is quite a lot. Are you sure?
 2000 simultaneous sessions isn't a stretch, but 2k connections is a big
 deal. How long are your transactions? What is the incoming request
 rate?
 

How about the more likely 2 connector scenario, one for port 80 one for port 
443?
Any benefit of using the executor here?  Assuming sharing one between 
connectors, and web.xml configured to auto-route everything to SSL, i.e. time 
spent on 80 is minimal (redirect)?

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

RE: Shutdown port on Windows Service installation

[Jeffrey Janner]

 -Original Message-
 From: David kerber [mailto:dcker...@verizon.net]
 Sent: Tuesday, March 04, 2014 8:17 AM
 To: Tomcat Users List
 Subject: Shutdown port on Windows Service installation
 
 I am running several instances of TC 7 as services on a Windows Server
 2008 R2.  Each instance has its own set of ports, and I have both the
 data port and shutdown ports configured in server.xml.  They are
 currently running only HTTP.
 
 My questions:
 
 1.  Does the shutdown port serve any purpose on a windows service
 installation?  I thought I had read that it did not, but some searching
 didn't turn up a definitive answer.
 
The shutdown port is not needed for a Windows service, but it is usable if 
configured.
In other words, assuming the default configuration, if someone were to send 
SHUTDOWN to the localhost port 8005, then Tomcat would shutdown.
I couldn't tell from the documentation 
(http://tomcat.apache.org/tomcat-7.0-doc/config/server.html), but I seem to 
recall that the port attribute is required on the Server tag.  For all my 
Windows installations, I just set it to -1 and let the Commons Daemon 
implementation (tomcat.exe) take care of the shutdown task.  
FYI: Tomcat implements the Java Daemon API, which is the mechanism that the 
Apache Commons Daemon (http://commons.apache.org/proper/commons-daemon/) 
executables use to communicate with the Tomcat. The ACD is a C program that 
loads the JVM and tells it to run the Tomcat bootstrap. Then it just listens 
for system signals.  There is a Windows version (procrun) and a Unix/Linux 
version (jsvc).  This is a separate utility that you can use if you have 
standalone Java programs you need to run as a service.
BTW: The JVM exits when Tomcat issues a System.exit() call.

 2.  I may need to start using HTTPS for my data transfer for at least
 one of the instances.  If that instance is going to allow only HTTPS
 (and not HTTP), can I just make the current HTTP port into HTTPS?  Or
 do I need to configure an additional port?  If I need an additional
 port, and the shutdown port isn't needed, I could just turn the
 shutdown port into the HTTPS port, right?
 
You don't mention your setup, but I would use the standard HTTPS port of 443 
and actually provide both the HTTP and HTTPS connectors, then configure the 
application to force HTTPS where necessary via the web.xml directives.
But then again, it depends on your implementation.

 I understand that there are significant configuration changes needed
 for HTTPS, and will be back if I run into issues with it, but for now
 I'm only asking about the TCP ports.
 
 Thanks!
 Dave

Be careful of whether you are also running with the native/APR library.  The 
SSL configuration requirements are different if doing so.  It is all well 
documented in the Tomcat documentation.
Jeff


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