Re: Off topic question

[Frank Tornack]

Maybe this would help you as a way to encrypt passwords


https://docs.jboss.org/jbosssecurity/docs/6.0/security_guide/html/Encrypting_The_Keystore_Password_In_Tomcat.html


Am Donnerstag, den 28.05.2020, 03:38 + schrieb
jonmcalexan...@wellsfargo.com.INVALID:
> I know this is off topic some, but does anyone know why development
> seemed to just stop on the tomcat-vault?
> 
> Thanks,
> 
> 
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Asst Vice President
> 
> Middleware Product Engineering
> Enterprise CIO | Platform Services | Middleware | Infrastructure
> Solutions
> 
> 8080 Cobblestone Rd | Urbandale, IA 50322
> MAC: F4469-010
> Tel 515-988-2508 | Cell 515-988-2508
> 
> jonmcalexan...@wellsfargo.com
> 
> 
> This message may contain confidential and/or privileged information.
> If you are not the addressee or authorized to receive this for the
> addressee, you must not use, copy, disclose, or take any action based
> on this message or any information herein. If you have received this
> message in error, please advise the sender immediately by reply e-
> mail and delete this message. Thank you for your cooperation.
> 


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

Re: How to write a filter in web.xml to accept partially a URL ?

[Frank Tornack]

Hi Gilbert,

maybe you have more luck with the security-constraint in tomcat.

kindly 
Frank

Am Samstag, den 25.04.2020, 08:47 -0400 schrieb Gilbert Soucy:
> Hello,
> 
> I am new to tomcat and I need to filter the URLs to accept all
> clients for
> part of a URL and reject for all clients another part of this URL.
> 
> In details, I want:
> 
> /abc/def/xyz/*   : accepts all
> /abc/def/*:  reject if URL does  not match /abc/def/xyz*
> 
> 
> I found that the order in which the filters are done is explained in
> this
> link (
> https://stackoverflow.com/questions/17086712/servlet-filters-order-of-execution
> ).
> 
> Based on this, I did the following 2 filters:
> 
> 1) Accept All : this one is the most precise url-pattern and is
> listed
> 1st. When matching, I hope to accept all IP addresses
> 
> 2) Block All  :  this one is more general and should match the
> rest of
> the URL when the 1st fitler does not match. I hope to reject all the
> IP in
> this case
> 
> Here are the filters, in the order that I add them in web.xml :
> 
> 
>   Accept All
>   org.apache.catalina.filters.RemoteAddrFilter class>
>   
> allow
> \d+\.\d+\.\d+\.\d+
>   
> 
> 
>   Accept All
>   /abc/def/xyz/*
> 
> 
> 
>   Block All
>   org.apache.catalina.filters.RemoteAddrFilter class>
>   
> deny
> \d+\.\d+\.\d+\.\d+
>   
> 
> 
>   Block All
>   /abc/def/*
> 
> 
> 
> The result is that all URLs  (  i.e.  /abc/def/* ) are jected and
> /abc/def/xyz/*  is never accepted.
> 
> Is there a way to do what I am trying to do ?
> 
> Thank you
> 
> Gilbert


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

Re: Alternatives for AJP

[Frank Tornack]

Chris,

Am Dienstag, den 14.04.2020, 10:56 -0400 schrieb Christopher Schultz:
> Frank,
> 
> On 4/12/20 10:20, Frank Tornack wrote:
> > It is possible to replace AJP with normal HTTP or HTTPs.
> > 
> > AJP has an advantage, it needs less bandwidth.
> 
> Reference?
https://marc.info/?l=tomcat-user=123404294317780
I think AJP has less overhead.

> 
> > But it shouldn't make too much difference with today's computer
> > networks. If you need the bandwidth advantage, you can certainly
> > use the module ModSecurity for Apache HTTPD to protect your
> > application server. But an advanced solution would be to protect
> > AJP with the IPTables firewall. AJP is mostly used in conjunction
> > with HTTPD and if you only allow access to these, it should be
> > pretty secure.
> 
> While a firewall (iptables) can be used to protect AJP, a much better
> solution would be mutually-authenticated stunnel. Even better, switch
> to mutually-authenticated https, which doesn't require a separate
> package to add the security layer.
why not both?
> 
> -chris
> 
> > Am Freitag, den 10.04.2020, 15:45 + schrieb David Cleary:
> > > Some of our customers are currently using the AJP connector.
> > > Given the vulnerability and breaking change to address it, now
> > > may be a good time to prompt them look at alternatives. One
> > > requirement is HTTPS support. What are the alternatives when
> > > hosting Tomcat behind Apache httpd, nginx, or IIS? I do remember
> > > a presentation I thought was pretty good at Apachecon in Miami on
> > > connectors a few years ago. Has there been anything new that has
> > > come out since then? Are there any recommendations on what is
> > > best to replace AJP13?
> > > 
> > > Thanks Dave
> > 
> > -
> > 
> > 
> > 
> 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: Alternatives for AJP

[Frank Tornack]

It is possible to replace AJP with normal HTTP or HTTPs.
AJP has an advantage, it needs less bandwidth. But it shouldn't make
too much difference with today's computer networks. If you need the
bandwidth advantage, you can certainly use the module ModSecurity for
Apache HTTPD to protect your application server. But an advanced
solution would be to protect AJP with the IPTables firewall. AJP is
mostly used in conjunction with HTTPD and if you only allow access to
these, it should be pretty secure.

Am Freitag, den 10.04.2020, 15:45 + schrieb David Cleary:
> Some of our customers are currently using the AJP connector. Given
> the vulnerability and breaking change to address it, now may be a
> good time to prompt them look at alternatives. One requirement is
> HTTPS support. What are the alternatives when hosting Tomcat behind
> Apache httpd, nginx, or IIS? I do remember a presentation I thought
> was pretty good at Apachecon in Miami on connectors a few years ago.
> Has there been anything new that has come out since then? Are there
> any recommendations on what is best to replace AJP13?
> 
> Thanks
> Dave


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

Re: tomcat7 does not log x-forwarded-for

[Frank Tornack]

hello all,

unfortunately, I haven't been able to find a clue as to what I'm doing
wrong. Currently, logging works with the direct entry of the HTTP
header. Unfortunately the automatic switching does not work yet. This
means that in case of direct requests, I have a minus sign at this
position. 

Do you have another idea? Thanks in advance.



Am Freitag, den 03.04.2020, 13:38 +0200 schrieb Frank Tornack:
> Hello Mark,
> 
> I could test the change today, unfortunately only with moderate
> success. The change to %a or %h, unfortunately did not work, but the
> readout with the header value per %{X-Forwarded-For}i worked. The log
> doesn't look nice, but we get the value. Nevertheless I am still
> looking for a nicer solution. I was really hoping on %a that we would
> only see the IP of the load balancer if no header is set, but still
> always see an IP.
> 
> Do you have any more ideas what to watch? 
> PS:For a Tomcat update I have to ask other contacts if it is easy to
> do.


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

Re: JNI memory leak?

[Frank Tornack]

Good evening,
I have a question about your e-mail address. Why does the address end
on com.INVALID? How do you get such an address?

Sorry for the interposed question,

Am Samstag, den 04.04.2020, 01:48 + schrieb Mark Boon:
> For the past few months we’ve been trying to trace what looks like
> gradual memory creep. After some long-running experiments it seems
> due to memory leaking when
> jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType,
> _jmethodID*, JNI_ArgumentPusher*, Thread*) is invoked. Somewhere.
> 
> My environment is Tomcat running a proxy webapp. It does TLS
> termination,  authentication and then forwards the call to local
> services. It doesn’t do much else, it’s a relatively small
> application.
> 
> Some (possibly relevant) versions and config parameters:
> Tomcat 8.5
> Java 8u241 (Oracle)
> Heap size = 360Mb
> MAX_ALLOC_ARENA=2
> MALLOC_TRIM_THRESHOLD_=250048
> jdk.nio.maxCachedBufferSize=25600
> 
> We couldn’t find any proof of memory leaking on the Java side.
> When we turn on NativeMemoryTracking=detail and we take a snapshot
> shortly after starting, we see (just one block shown):
> 
> [0x03530e462f9a] JNIHandleBlock::allocate_block(Thread*)+0xaa
> [0x03530e3f759a] JavaCallWrapper::JavaCallWrapper(methodHandle,
> Handle, JavaValue*, Thread*)+0x6a
> [0x03530e3fa000] JavaCalls::call_helper(JavaValue*,
> methodHandle*, JavaCallArguments*, Thread*)+0x8f0
> [0x03530e4454a1] jni_invoke_static(JNIEnv_*, JavaValue*,
> _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)
> [clone .isra.96] [clone .constprop.117]+0x1e1
>  (malloc=33783KB type=Internal #110876)
> 
> Then we run it under heavy load for a few weeks and take another
> snapshot:
> 
> [0x03530e462f9a] JNIHandleBlock::allocate_block(Thread*)+0xaa
> [0x03530e3f759a] JavaCallWrapper::JavaCallWrapper(methodHandle,
> Handle, JavaValue*, Thread*)+0x6a
> [0x03530e3fa000] JavaCalls::call_helper(JavaValue*,
> methodHandle*, JavaCallArguments*, Thread*)+0x8f0
> [0x03530e4454a1] jni_invoke_static(JNIEnv_*, JavaValue*,
> _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)
> [clone .isra.96] [clone .constprop.117]+0x1e1
>  (malloc=726749KB type=Internal #2385226)
> 
> While other blocks also show some variation, none show growth like
> this one. When I do some math on the number (726749KB - 33783KB) /
> (2385226 – 110876) it comes down to a pretty even 312 bytes per
> allocation.
> And we leaked just under 700Mb. While not immediately problematic,
> this does not bode well for our customers who run this service for
> months.
> 
> I’d like to avoid telling them they need to restart this service
> every two weeks to reclaim memory. Has anyone seen something like
> this? Any way it could be avoided?
> 
> Mark Boon
> 
> 
> 


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

Re: tomcat7 does not log x-forwarded-for

[Frank Tornack]

Hello Mark,

I could test the change today, unfortunately only with moderate
success. The change to %a or %h, unfortunately did not work, but the
readout with the header value per %{X-Forwarded-For}i worked. The log
doesn't look nice, but we get the value. Nevertheless I am still
looking for a nicer solution. I was really hoping on %a that we would
only see the IP of the load balancer if no header is set, but still
always see an IP.

Do you have any more ideas what to watch? 
PS:For a Tomcat update I have to ask other contacts if it is easy to
do.
-- 
Frank Tornack 


Am Mittwoch, den 01.04.2020, 09:35 +0100 schrieb Mark Thomas:
> On 01/04/2020 06:56, Frank Tornack wrote:
> > Am Dienstag, den 31.03.2020, 15:47 +0100 schrieb Mark Thomas:
> > > On 31/03/2020 07:26, Frank Tornack wrote:
> 
> 
> 
> > > > We used the following configuration for access logging and
> > > > remote
> > > > valve:
> > > >  > > > internalProxies="xxx\.xxx\.xxx\.7|xxx\.xxx\.xxx\.8|xxx\.xxx\.xx
> > > > x\.9
> > > > "  remoteIpHeader="X-Forwarded-For" />
> > > 
> > > The remoteIpHeader setting is unnecessary. That is the default.
> > The way I understand you, it shouldn't bother? I had added it
> > because I
> > was not sure about the capitalization.
> 
> Correct. The names of HTTP headers are not case-sensitive. Tomcat
> looks
> them up in a case insensitive manner.
> 
> > > >  > > > directory="logs"
> > > > prefix="access_log." suffix=".log"
> > > > pattern="%{org.apache.catalina.AccessLog.RemoteAddr}r %l %u %t
> > > > %r %s %b" 
> > > > requestAttributesEnabled="true" />
> > > 
> > > That isn't correct. You only need to add
> > > requestAttributesEnabled="true"
> > > to the default AccessLogValve. It will handle looking up the
> > > correct
> > > attributes. You don't need to modify the pattern.
> > I already worked with a modified log layout before the change. I
> > only
> > changed the %{org.apache.catalina.AccessLog.RemoteAddr}r. So would
> > I
> > have to replace %{org.apache.catalina.AccessLog.RemoteAddr}r with a
> > %a?
> 
> I was using %h but %a should work just as well. Let me check ... yes
> it
> does.
> 
> > > I also confirmed that the Valve order doesn't matter.
> > So not like many on the Internet claim it matters?
> 
> Many on the internet are often wrong. Or at least the information
> they
> present is incomplete, out of date and/or out of context.
> 
> In this specific instance, Valve order is irrelevant.
> 
> The general case is a request/response passes through the Valves
> (Engine
> level Valves in order of definition, then Host Valves in order, then
> Context Valves in order), gets processed by the application and then
> returns through the valves in reverse order.
> 
> So, generally, order is important. However, there are some
> exceptions.
> 
> A Valve can choose not to pass the request/response on to the next
> stage
> but to generate the response itself and return the request/response
> back
> through the Valves it has passed through to that point.
> 
> The AccessLogValve is the other exception. It does not generate the
> log
> entry at the point where the request/response passes through it. It
> used
> to a long time ago but that changed with the fix for bug 50582 (in
> 2011).
> 
> It is important which Container (Engine, Host or Context) that the
> Valve
> is added to since that will determine which request/response pairs
> get
> logged.
> 
> > > > The request header 'X-Forwarded-For'
> > > > was set and load balancer was analyzed via wireshark and
> > > > Request
> > > > Dumper
> > > > Filter. We can see the header in both. However we still only
> > > > get
> > > > the IP
> > > > of the load balancer and not the IP of the remote client. The
> > > > IP
> > > > adresses of the config have already been checked and they are
> > > > correct.
> > > 
> > > You can add "... %{X-Forwarded-For}i ..." to the pattern
> > > attribute of
> > > the AccessLog valve to confirm that Tomcat sees this header
> > > value.
> > In the beginning we tested it with Wireshark, later with a
> > RequestDumper in the Tomcat. In both we saw the header.
> > 
> > > I've tested this locally with the latest 7.0.x and everything
> > > works
> > > a

Re: tomcat7 does not log x-forwarded-for

[Frank Tornack]

Good morning all,

the answers are [inline].

With kind regards
Frank

Am Dienstag, den 31.03.2020, 15:47 +0100 schrieb Mark Thomas:
> On 31/03/2020 07:26, Frank Tornack wrote:
> > Hello all,
> > 
> > I currently have a problem with Tomcat7, or rather a colleague has
> > it.
> > Personally I would like to help him, but I can't find the error
> > myself.
> > We already asked the question on stackoverflow.com and got a good
> > hint,
> > but unfortunately no solving. So I would like to ask for help and
> > support here. I think I am violating the directive of asking a
> > double
> > question, but it is important to me personally to help this
> > colleague.
> > Therefore I am at least honest, the question can also be found at
> > the
> > link: 
> > https://stackoverflow.com/questions/60827540/tomcat-x-forwarded-for-doesnt-work-with-load-balancer
> 
> Which at least enables us to find the one key piece of information
> missing in this question, the version of Tomcat being used: 7.0.76
Sorry I forgot to include this information in the mail.

> 
> > We run a software that uses Tomcat as application server behind a
> > load
> > balancer. Now we would like to record the initial address of the
> > requests and not the IP of the load balancer. We have used these 3
> > websites for the setup, but unfortunately it does not work. The IPs
> > of
> > the loadbalancers are still written to the access log. 
> > https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valves/RemoteIpValve.html
> > https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valves/AccessLogValve.html
> > https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Remote_IP_Valve
> > 
> > We used the following configuration for access logging and remote
> > valve:
> >  > internalProxies="xxx\.xxx\.xxx\.7|xxx\.xxx\.xxx\.8|xxx\.xxx\.xxx\.9
> > "  r
> > emoteIpHeader="X-Forwarded-For" />
> 
> The remoteIpHeader setting is unnecessary. That is the default.
The way I understand you, it shouldn't bother? I had added it because I
was not sure about the capitalization.

> 
> >  > directory="logs"
> > prefix="access_log." suffix=".log"
> > pattern="%{org.apache.catalina.AccessLog.RemoteAddr}r %l %u %t
> > %r %s %b" 
> > requestAttributesEnabled="true" />
> 
> That isn't correct. You only need to add
> requestAttributesEnabled="true"
> to the default AccessLogValve. It will handle looking up the correct
> attributes. You don't need to modify the pattern.
I already worked with a modified log layout before the change. I only
changed the %{org.apache.catalina.AccessLog.RemoteAddr}r. So would I
have to replace %{org.apache.catalina.AccessLog.RemoteAddr}r with a %a?

> 
> I also confirmed that the Valve order doesn't matter.
So not like many on the Internet claim it matters?

> 
> > The request header 'X-Forwarded-For'
> > was set and load balancer was analyzed via wireshark and Request
> > Dumper
> > Filter. We can see the header in both. However we still only get
> > the IP
> > of the load balancer and not the IP of the remote client. The IP
> > adresses of the config have already been checked and they are
> > correct.
> 
> You can add "... %{X-Forwarded-For}i ..." to the pattern attribute of
> the AccessLog valve to confirm that Tomcat sees this header value.
In the beginning we tested it with Wireshark, later with a
RequestDumper in the Tomcat. In both we saw the header.

> 
> I've tested this locally with the latest 7.0.x and everything works
> as
> expected. I also don't recall any changes / bugs in this area
> recently.
> 
> A quick scan of the changelog does identify various improvements and
> fixes since 7.0.76 but none that immediately jump out as likely to
> cause
> this simple configuration to fail.
Thanks for looking into it.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

Re: tomcat7 does not log x-forwarded-for

[Frank Tornack]

Good morning all,

the answers are [inline].

With kind regards
Frank

Am Dienstag, den 31.03.2020, 10:08 -0400 schrieb Christopher Schultz:
> Frank,
> 
> On 3/31/20 02:26, Frank Tornack wrote:
> > I currently have a problem with Tomcat7, or rather a colleague has
> > it.
> 
> Which exact version of Tomcat 7?
It is version: 7.0.76
> 
> > Personally I would like to help him, but I can't find the error
> > myself. We already asked the question on stackoverflow.com and got
> > a good hint, but unfortunately no solving. So I would like to ask
> > for help and support here. I think I am violating the directive of
> > asking a double question, but it is important to me personally to
> > help this colleague. Therefore I am at least honest, the question
> > can also be found at the link:
> > https://stackoverflow.com/questions/60827540/tomcat-x-forwarded-for-do
> esnt-work-with-load-balancer
> >  We run a software that uses Tomcat as application server behind a
> > load balancer. Now we would like to record the initial address of
> > the requests and not the IP of the load balancer. We have used
> > these 3 websites for the setup, but unfortunately it does not work.
> > The IPs of the loadbalancers are still written to the access log.
> > https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valve
> s/RemoteIpValve.html
> > 
> https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valves/
> AccessLogValve.html
> > https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Remote_IP_V
> alve
> 
> You
> are at least on the right track.
Thank you. I had the hope not to run completely in the wrong direction.
> 
> > We used the following configuration for access logging and remote
> > valve:  > internalProxies="xxx\.xxx\.xxx\.7|xxx\.xxx\.xxx\.8|xxx\.xxx\.xxx\.9
> > "
> > r emoteIpHeader="X-Forwarded-For" />  > className="org.apache.catalina.valves.AccessLogValve"
> > directory="logs" prefix="access_log." suffix=".log"
> > pattern="%{org.apache.catalina.AccessLog.RemoteAddr}r %l %u %t
> > %r %s %b" requestAttributesEnabled="true" />
> 
> What is the IP address of your load-balancer(s)? One of those
> xxx.xxx.xxx.[789]?
the used load balancer uses three network cards in the Tomcat network.
We have not yet set up a grouping of the network cards, so all IPs are
listed here and linked with "or".
> 
> > The request header 'X-Forwarded-For' was set and load balancer was
> > analyzed via wireshark and Request Dumper Filter. We can see the
> > header in both. However we still only get the IP of the load
> > balancer and not the IP of the remote client. The IP adresses of
> > the config have already been checked and they are correct.
> > 
> > Thank you very much in advance for your support.
> 
> Please post the  that you are using to receive requests
> from your load-balancer.



> 
> Are you seeing any warnings/errors in your log file when Tomcat
> starts? During the first few requests?
There are some errors, but as far as I know only application errors and
none from Tomcat itself. 
> 
> -chris
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

Re: Why does Tomcat open connections on localhost?

[Frank Tornack]

Yes, these too are for communication between processes. Only you don't
use the network stack. This is a special feature of Unix-like operating
systems.

DGRAM, unlike STREAM, does not know connection states. Therefore STREAM
is comparable to a local TCP connection. Unix domain sockets exist in
the file tree as special files. Access is controlled by file
permissions, as is usual for files. 

Am Dienstag, den 31.03.2020, 14:29 +0200 schrieb André Warnier
(tomcat/perl):
> On 31.03.2020 14:20, Mark Thomas wrote:
> > On 31/03/2020 11:20, Aditya Kumar wrote:
> > > Tomcat 9.0.30 on Windows Server 2012 / Java 1.8
> > > 
> > > I've noticed on a freshly installed version of tomcat 9, upon
> > > startup there
> > > are several connections to and from localhost on different ports
> > > 
> > > For example on my tomcat server there are 4 connections to and
> > > from
> > > localhost (output from netstat)
> > > 
> > >  
> > > TCP0.0.0.0:8080   0.0.0.0:0  LISTENING   
> > > 3972
> > >  
> > > TCP127.0.0.1:55618127.0.0.1:55619ESTABLISHED 
> > > 3972
> > >  
> > > TCP127.0.0.1:55619127.0.0.1:55618ESTABLISHED 
> > > 3972
> > >  
> > > TCP127.0.0.1:55620127.0.0.1:55621ESTABLISHED 
> > > 3972
> > >  
> > > TCP127.0.0.1:55621127.0.0.1:55620ESTABLISHED 
> > > 3972
> > >  
> > > TCP[::]:8080  [::]:0 LISTENING   
> > > 3972
> > > 
> > > These can grow to a large number (several thousand) on a busy
> > > system. What
> > > are these connections used for? What caused them? What thread are
> > > they
> > > attributed to?
> > 
> > The Java NIO implementation on Windows uses TCP for intra-process
> > signalling. It opens a pair of self-connected sockets for every
> > Selector.
> > 
> > Mark
> > 
> 
> While we're at it, under Linux, are the following for a similar
> reason ?
> 
> output of :  netstat -pan | grep 27514   (tomcat's JVM PID = 27514)
> [...]
> unix  2  [ ] STREAM CONNECTED 167427210
> 27514/java
> unix  2  [ ] STREAM CONNECTED 167423436
> 27514/java
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

Re: Why does Tomcat open connections on localhost?

[Frank Tornack]

Hi Aditya,

I'm not quite sure, but it could be a replacement for the sockets that
a Linux system provides for inter-process communication.

But it's just a guess, because I don't see this behavior on Linux.

kindly
Frank

Am Dienstag, den 31.03.2020, 11:20 +0100 schrieb Aditya Kumar:
> Tomcat 9.0.30 on Windows Server 2012 / Java 1.8
> 
> I've noticed on a freshly installed version of tomcat 9, upon startup
> there
> are several connections to and from localhost on different ports
> 
> For example on my tomcat server there are 4 connections to and from
> localhost (output from netstat)
> 
>  TCP0.0.0.0:8080   0.0.0.0:0  LISTENING  
>  3972
>  TCP127.0.0.1:55618127.0.0.1:55619ESTABLISHED
>  3972
>  TCP127.0.0.1:55619127.0.0.1:55618ESTABLISHED
>  3972
>  TCP127.0.0.1:55620127.0.0.1:55621ESTABLISHED
>  3972
>  TCP127.0.0.1:55621127.0.0.1:55620ESTABLISHED
>  3972
>  TCP[::]:8080  [::]:0 LISTENING  
>  3972
> 
> These can grow to a large number (several thousand) on a busy system.
> What
> are these connections used for? What caused them? What thread are
> they
> attributed to?


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

tomcat7 does not log x-forwarded-for

[Frank Tornack]

Hello all,

I currently have a problem with Tomcat7, or rather a colleague has it.
Personally I would like to help him, but I can't find the error myself.
We already asked the question on stackoverflow.com and got a good hint,
but unfortunately no solving. So I would like to ask for help and
support here. I think I am violating the directive of asking a double
question, but it is important to me personally to help this colleague.
Therefore I am at least honest, the question can also be found at the
link: 
https://stackoverflow.com/questions/60827540/tomcat-x-forwarded-for-doesnt-work-with-load-balancer

We run a software that uses Tomcat as application server behind a load
balancer. Now we would like to record the initial address of the
requests and not the IP of the load balancer. We have used these 3
websites for the setup, but unfortunately it does not work. The IPs of
the loadbalancers are still written to the access log. 
https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valves/RemoteIpValve.html
https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valves/AccessLogValve.html
https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Remote_IP_Valve

We used the following configuration for access logging and remote
valve:



The request header 'X-Forwarded-For'
was set and load balancer was analyzed via wireshark and Request Dumper
Filter. We can see the header in both. However we still only get the IP
of the load balancer and not the IP of the remote client. The IP
adresses of the config have already been checked and they are correct.

Thank you very much in advance for your support.

With kindest regards
Frank


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