Starting and stopping contexts programmatically

2016-03-14 Thread James H. H. Lampert
The only ways I know of to start and stop individual webapp contexts is 
to (1) start and stop them from the manager, or (2) start and stop 
Tomcat itself.


Is there a way, from the back end, to start and stop individual contexts?

--
James H. H. Lampert

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



Re: How can I fix deserialization vulnerability?

2016-03-14 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark,

On 3/11/16 4:10 AM, Mark Thomas wrote:
> On 11/03/2016 01:43, Christopher Schultz wrote:
>> 林慶龍,
>> 
>> On 3/10/16 8:07 PM, 林慶龍 Barry Lin wrote:
>>> These days, Everyone talks about the vulnerability in Tomcat,
>>> and we found that we had the same problem with “deserialization
>>>  vulnerability”.
>> 
>>> How can I fix deserialization vulnerability in tomcat?
>> 
>> If you don't have any applications that have known problematic
>> classes in them (such as the famous commons-collections bug),
>> then you aren't really in any danger.
> 
> That statement is dangerously incorrect.

I disagree, though my statement may easily be misunderstood.

> The vulnerability is not in Commons Collections or any of the
> various other libraries that have been leveraged in the various
> examples that have been made public.
> 
> The vulnerability is always that an application takes data from an 
> untrusted source and deserializes it without validation and/or 
> sanitation. If your application does this then you are almost
> certainly vulnerable to a deserialization attack of some form.

The vulnerability is in neither the library (e.g. commons-collections)
nor the application (Tomcat, in this case). Instead, the vulnerability
is in the interaction between the two of them.

Specifically, if you are using an application (Tomcat) that is
"vulnerable" (because it unsafely de-serializes untrusted streams) but
no "vulnerable" library is present, then it is not possible to exploit
this vulnerability.

>> You can disable session serialization, but if you don't trust
>> the files on your own disk then you probably have bigger
>> problems.
>> 
>> You can disable clustering, but if you don't trust the other
>> members of your cluster, then you probably have bigger problems.
>> 
>> You can disable session persistence, but if you don't trust your 
>> database, then you probably have bigger problems.
> 
> In 99.99% if use cases none of the above will be a problem since
> the data is trusted.
> 
> The vulnerability *only* applies when running untrusted web
> applications under a security manager (think hosting provider that
> only allows users to host WARs and uses a security manager to limit
> what those WARs can do). Because serialization and deserialization
> is performed by trusted code, it was possible for an untrusted web
> application to place a malicious object in the session that would,
> on deserialization, execute some code that would normally be
> blocked by the SecurityManager. If effect, this was a way for an
> untrusted app to bypass the constraints imposed by the
> SecurityManager.
> 
>> The reality is that this "deserialization vulnerability" is
>> wildly overblown. Yes, it should be mitigated, but the attack
>> vectors are very, very narrow.
> 
> Agreed.
> 
>> As of Tomcat 8.0.32, the session resumption "vulnerability" has
>> been mitigated in Tomcat itself if you configure it properly.
>> It's covered under "CVE-2016-0714" on this page: 
>> https://tomcat.apache.org/security-8.html
>> 
>> You need to either run Tomcat under a SecurityManager (in which
>> case, you'll get a non-null default value for this configuration
>> setting), or you need to set sessionAttributeValueClassNameFilter
>> on your  element in server.xml. 
>> https://tomcat.apache.org/tomcat-8.0-doc/config/manager.html
> 
> If you aren't running Tomcat under a security manager web
> applications can do whatever they like so this vulnerability is
> irrelevant.

I disagree. If you aren't running under a SecurityManager, it's still
possible (yet unlikely) for an attacker to inject a Trojan Horse into
Tomcat's session store. For example, a local user might be able to
escalate their privileges if they only have write access to the
session store. A SecurityManager might not help protect against such a
Trojan Horse, so the vulnerability IMO is definitely important even
under a SM.

>> (I admit I find the use of that CVE a little confusing, here, but
>> the patches for that CVE are the ones that also fix the
>> de-serialization vulnerability.)
> 
> What do you find confusing? I've re-read the CVE description and I 
> really can't see where it is unclear but given I wrote it pointers
> to what is unclear would be welcome.

I'm sorry, I must have been reading the wrong CVE. Re-checking them,
they are entirely accurate. (I had initially read the Tomcat
documentation saying something about a problem with the "Tomcat
manager", which wasn't the case). Apologies for the noise.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlbnJpoACgkQ9CaO5/Lv0PDiIgCgtPM6gqprqDsIWy2pQTNj/EkW
5kEAnR5MBH+97zrdkwjJKLjuk6+Her6X
=zim9
-END PGP SIGNATURE-

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

Re: Question about your recent security (CVE-2015-5345) fix in 7.0.68 build

2016-03-14 Thread Harish Krishnan
Any help on my previous question is really appreciated.
Thank You!

On Fri, Mar 11, 2016 at 4:05 PM, Harish Krishnan 
wrote:

> Thanks again for the reply, Chris & Violeta!
> Thanks for clarifying what the "protected directory" is, even i guessed it
> to be same. Now i understood the fix for the directories protected by a
> security constraint. I also verified this & the redirect is no more
> happening for these protected ones. Really appreciate your help here.
>
> However, i am still unable to disable the redirect for the root of the
> webapp. This is what i did on the latest tomcat build (7.0.68) -
>
> a) Set the context attribute (mapperContextRootRedirectEnabled) to false
> for manager webapp. Here is my context.xml (from
> \webapps\manager\META-INF\) file -
>
>  antiResourceLocking="false" privileged="true" >
>  
>
> b) Accessing http://localhost:8080/manager gets redirected to manger/.
>
> c) I have also set the above context attribute in the default context.xml
> (from \conf\context.xml) file as well.
>
> d) Accessing http://localhost:8080/examples gets redirected to examples/.
>
> Not sure what i am missing here. Same behavior is seen on my web
> application too.
> Please let me know where i am doing wrong & help me on how to disable the
> redirect for the root of webapps.
>
>
> regards
> Harish Krishnan
>
>
>
>
>
>
>
> On Wed, Mar 9, 2016 at 7:29 AM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> Harish,
>>
>> On 3/8/16 5:47 PM, Harish Krishnan wrote:
>> > Thanks Chris for the reply.
>> > Looks like my understanding of the fix is incorrect.
>> > I assumed (my bad) that, with the fix for this CVE in place (tomcat
>> > 7.0.68) + setting the additional context attribute
>> > (mapperContextRootRedirectEnabled="false"), all the redirects for that
>> > webapp where context attribute was set, will completely be disabled.
>> > You mentioned that only "protected directories" inside the deployed web
>> > application is covered in this CVE fix.
>> > Can you please help me understand what this protected directories are &
>> how
>> > to configure this in tomcat ?
>>
>> A "protected directory" is one that has a  in
>> web.xml. That's not a spec-defined term... just one we've been using
>> because it captures the meaning with fewer words.
>>
>> As for the redirects you are seeing that "expose" the availability of a
>> particular web application, those are essentially impossible to prevent,
>> and not considered a part of the CVE.
>>
>> -chris
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>


RE: Tomcat 6.x 32bit-- becomes non responsive state / crash/hang

2016-03-14 Thread Mahudeswaran A
Hello Mark,
Thank you

We are working in different time zone. & We will try the thread dump 
meantime...Would you like to share any check points in thread dump or share 
some troubleshooting steps/tools to identify the issue.
The visualgc plugin in jvisualvm is not supported for the jvm 1.6.

Is there any configuration to include timestamp in tomcat std.out or std.err 
log files.

**Attached is the sequence flow that we are trying in our load environment;

Itr-1: If we attach a commercial tool (forget the name-it something like 
yourjdk... will share you as soon as I get) the jvm crashes within 10-15 
minutes;
Thread-count=150
Itr-2: If we attach a commercial tool (forget the name-it something like 
yourjdk... will share you as soon as I get) the jvm crashes within 50-55 
minutes;
Thread-count=300
Itr-3: If we attach a commercial tool (forget the name-it something like 
yourjdk... will share you as soon as I get) the jvm crashes within 50-55 
minutes;
Thread-count=30
Itr-4: The commercial tool was disconnected from jvm monitoring and started the 
load with thread-count=30; & last few hours before checked it's was 
running;monitoring with jvisualvm.

Regards
Mahu
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: 14 March 2016 20:14
To: Tomcat Users List
Subject: Re: Tomcat 6.x 32bit-- becomes non responsive state / crash/hang

On 14/03/2016 14:41, Mahudeswaran A wrote:
> Hi,
> 
> We are facing unusual issue in Tomcat 6.x, where Tomcat 6.x becomes non 
> responsive state after two week's time.
> This happens randomly;
> The jvisualvm screen shows CPU, memory, thread are normal and we don't see 
> memory leak, thread leak or CPU hike.
> JVM running is 32 bit;
> In our lab, we are simulating this issue by running a load but still trying 
> our level best but couldn't.
> Min heap=256MB; Max heap=512MB
> Thread count=150
> Tomcat idle session timeout=30minutes
> In out load environment the thread count reduced to 30;
> 
> Any insights on why the tomcat becomes non responsive;

Take a series of 3 thread dumps, ~15s apart. If you need help analysing them, 
post them here.

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: How to comply with http://www.sitemaps.org/protocol.html#location

2016-03-14 Thread Lyallex
Oh ... well ... how smart is that, works like a dream, nice one

Thanks
Lyallex

On 14 March 2016 at 10:34, Terence M. Bandoian  wrote:
> On 3/13/2016 10:23 AM, Lyallex wrote:
>>
>> CentOS 5.2
>> jdk1.7.0_45
>> apache-tomcat-7.0.42
>> no httpd, tomcat only, one webapp ROOT.war
>>
>> According to the documentation at
>>
>> http://www.sitemaps.org/protocol.html#location
>>
>> An xml sitemap should appear in the context root, if it dosn't it can
>> only contain a limited set of urls.
>>
>> Currently, whenever I add a new product for sale I auto generate
>> sitemap.xml and write it to a remote context called sitemap giving me
>> the sitemap URL
>>
>> www.mysite.com/sitemap/sitemap.xml which I detail in robots.txt
>>
>> However this is apparently incorrect and sitemap.xml should live at
>> www.mysite.com/sitemap.xml. Unfortunately it is not possible to write
>> to the root of my web app on the fly so how do people deal with this ?
>>
>> Thanks
>> Lyallex
>>
>
>
> One solution might be to write a servlet mapped to /sitemap.xml that reads
> sitemap.xml from an alternate location and sends the contents as a response
> to any requests for /sitemap.xml
>
> -Terence Bandoian
>  http://www.tmbsw.com/
>
>
> -
> 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 6.x 32bit-- becomes non responsive state / crash/hang

2016-03-14 Thread Mark Thomas
On 14/03/2016 14:41, Mahudeswaran A wrote:
> Hi,
> 
> We are facing unusual issue in Tomcat 6.x, where Tomcat 6.x becomes non 
> responsive state after two week's time.
> This happens randomly;
> The jvisualvm screen shows CPU, memory, thread are normal and we don't see 
> memory leak, thread leak or CPU hike.
> JVM running is 32 bit;
> In our lab, we are simulating this issue by running a load but still trying 
> our level best but couldn't.
> Min heap=256MB; Max heap=512MB
> Thread count=150
> Tomcat idle session timeout=30minutes
> In out load environment the thread count reduced to 30;
> 
> Any insights on why the tomcat becomes non responsive;

Take a series of 3 thread dumps, ~15s apart. If you need help analysing
them, post them here.

Mark


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



Tomcat 6.x 32bit-- becomes non responsive state / crash/hang

2016-03-14 Thread Mahudeswaran A
Hi,

We are facing unusual issue in Tomcat 6.x, where Tomcat 6.x becomes non 
responsive state after two week's time.
This happens randomly;
The jvisualvm screen shows CPU, memory, thread are normal and we don't see 
memory leak, thread leak or CPU hike.
JVM running is 32 bit;
In our lab, we are simulating this issue by running a load but still trying our 
level best but couldn't.
Min heap=256MB; Max heap=512MB
Thread count=150
Tomcat idle session timeout=30minutes
In out load environment the thread count reduced to 30;

Any insights on why the tomcat becomes non responsive;

Thanks & Regards



Re: [COMMERCIAL] Re: Need Help: - jk doesn't work after upgrade to 1.2.40 from 1.2.23

2016-03-14 Thread tomcat

Hi Eric.

A couple of things :
1) Martin is right, in the sense that if a "worker" is mentioned in the loadbalancer 
configuration ("balance_workers"), then normally you should /not/ also list it in the list 
of individual "workers" in the "worker.list" directive.
2) I am not even sure that you really have a problem : the logfile part that you are 
showing, shows "[debug]" lines with the "Missing URI map.." messages.
These are not errors (otherwise they would be marked "[error]"), they are trace messages 
allowing you to figure out what is going on when debugging a problem.
A "missing URI map" just indicates that mod_jk is trying to match the URI of the current 
request with one of the "JkMount" URI's, and failing *for the worker which it is now 
trying to match*.  That does not necessarily mean that it will fail to match this URI with 
some other worker.
3) the debug messages show a prefix like "IBM001OAM01:". What does that correspond to ? I 
do not see this name in the JkMount directives that you show, nor in the part of 
workers.properties that you show.

4) I am a bit puzzled by this section :
>>> worker.ajp12.port=8007
>>> worker.ajp12.host=localhost
>>> worker.ajp12.type=ajp12

What is this type "ajp12" ? As far as I know, this does not exist, see
http://tomcat.apache.org/connectors-doc/reference/workers.html
Mandatory Directives -> type

And finally, do you have a problem, and what is it ?
What really happens when you try to access a URI like 
"http://(hostname)/sso/lsm/lsm.jnlp" ?

And could you provide a *complete* list of your (Jk*) configuration directives, and a 
complete content of the workers.properties file ?

And maybe a short description as to what you are trying to achieve.
From what you provided so far, it is not very clear which URI's you want to 
"load-balance" and which not.
The fact that "it worked before" is no guarantee that what you had before was entirely 
correct.





On 14.03.2016 11:47, Martin Knoblauch wrote:

Hi Eric,

  there are two things different from *my* working "mod_jk/1.2.41" setup:

a) I have only the "JkMount /xxx/* xxx" line in my configuration
b) in the workers list I have only the loadbalancer and the management
workers listed, not the individual ones. Not sure how relevant this is

Martin


On Mon, Mar 14, 2016 at 8:24 AM, ZHAO Eric 
wrote:


Dear Andre,

Thanks for your response!
We didn't use Virtual Host in our setting.  I re-read the documentation
and didn't find anything wrong with the setting, also this setting worked
before. Do you have several minutes to check the setting in our server for
mod_jk?  Appreciate for your time.

Best Regards,
Eric.

-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
Sent: Saturday, March 12, 2016 10:18 PM
To: users@tomcat.apache.org
Subject: [COMMERCIAL] Re: Need Help: - jk doesn't work after upgrade to
1.2.40 from 1.2.23

On 12.03.2016 15:04, ZHAO Eric wrote:

Hello,

I am new to Tomcat Connectors, we are trying to upgrade the existing

mod_jk 1.2.23 to 1.2.40 for IPV6 configuration.


But we always got the following error in jk.log with 1.2.40, we don't

know if anything need to adjust after upgrade to the new version:

[Thu Mar 10 17:45:10.790 2016] [13878:140261127514080] [debug]
jk_translate::mod_jk.c (3855): missing uri map for
IBM001OAM01:/sso/lsm/lsm.jnlp [Thu Mar 10 17:45:10.790 2016]
[13878:140261127514080] [debug] jk_map_to_storage::mod_jk.c (4023):
missing uri map for IBM001OAM01:/sso/lsm/lsm.jnlp

Can some one help me out from this issue? Appreciated in advance, the

following are the setting, we don't have uriworkermapping.properties file..


Here is our setting for mod_jk:
mod_jk.conf:

LoadModule jk_module /usr/lib64/httpd/modules/mod_jk.so


JkWorkersFile /etc/httpd/conf/workers.properties
JkLogFile /var/log/jk.log
# JkLogLevel debug
JkLogLevel warning

JkMount /MIBS ajp12
JkMount /MIBS/* ajp12
...
JkMount /sso csajboss
JkMount /sso/* csajboss


workers.properties:
worker.list=ajp12,soapnbi,csajboss,csawebsso,loadbalancer,cfmaplayer1,
cfmaplayer2,cfmaplayer3

worker.ajp12.port=8007
worker.ajp12.host=localhost
worker.ajp12.type=ajp12

# Added for SOAP NBI
worker.soapnbi.port=8009
worker.soapnbi.host=localhost
worker.soapnbi.type=ajp13

# Added for CSA - JBOSS
worker.csajboss.port=8011
worker.csajboss.host=c04s02h02IBM2
worker.csajboss.type=ajp13

#// next are lb related.



Does this happen in an Apache httpd VirtualHost ?
If yes, make sure that you re-read the configuration documentation at
http://tomcat.apache.org/connectors-doc/reference/apache.html
and in particular, the sections about JkMount and JkMountCopy.


-
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 

Re: [COMMERCIAL] Re: Need Help: - jk doesn't work after upgrade to 1.2.40 from 1.2.23

2016-03-14 Thread Martin Knoblauch
Hi Eric,

 there are two things different from *my* working "mod_jk/1.2.41" setup:

a) I have only the "JkMount /xxx/* xxx" line in my configuration
b) in the workers list I have only the loadbalancer and the management
workers listed, not the individual ones. Not sure how relevant this is

Martin


On Mon, Mar 14, 2016 at 8:24 AM, ZHAO Eric 
wrote:

> Dear Andre,
>
> Thanks for your response!
> We didn't use Virtual Host in our setting.  I re-read the documentation
> and didn't find anything wrong with the setting, also this setting worked
> before. Do you have several minutes to check the setting in our server for
> mod_jk?  Appreciate for your time.
>
> Best Regards,
> Eric.
>
> -Original Message-
> From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
> Sent: Saturday, March 12, 2016 10:18 PM
> To: users@tomcat.apache.org
> Subject: [COMMERCIAL] Re: Need Help: - jk doesn't work after upgrade to
> 1.2.40 from 1.2.23
>
> On 12.03.2016 15:04, ZHAO Eric wrote:
> > Hello,
> >
> > I am new to Tomcat Connectors, we are trying to upgrade the existing
> mod_jk 1.2.23 to 1.2.40 for IPV6 configuration.
> >
> > But we always got the following error in jk.log with 1.2.40, we don't
> know if anything need to adjust after upgrade to the new version:
> > [Thu Mar 10 17:45:10.790 2016] [13878:140261127514080] [debug]
> > jk_translate::mod_jk.c (3855): missing uri map for
> > IBM001OAM01:/sso/lsm/lsm.jnlp [Thu Mar 10 17:45:10.790 2016]
> > [13878:140261127514080] [debug] jk_map_to_storage::mod_jk.c (4023):
> > missing uri map for IBM001OAM01:/sso/lsm/lsm.jnlp
> >
> > Can some one help me out from this issue? Appreciated in advance, the
> following are the setting, we don't have uriworkermapping.properties file.
> >
> > Here is our setting for mod_jk:
> > mod_jk.conf:
> > 
> >LoadModule jk_module /usr/lib64/httpd/modules/mod_jk.so
> > 
> >
> > JkWorkersFile /etc/httpd/conf/workers.properties
> > JkLogFile /var/log/jk.log
> > # JkLogLevel debug
> > JkLogLevel warning
> >
> > JkMount /MIBS ajp12
> > JkMount /MIBS/* ajp12
> > ...
> > JkMount /sso csajboss
> > JkMount /sso/* csajboss
> >
> >
> > workers.properties:
> > worker.list=ajp12,soapnbi,csajboss,csawebsso,loadbalancer,cfmaplayer1,
> > cfmaplayer2,cfmaplayer3
> >
> > worker.ajp12.port=8007
> > worker.ajp12.host=localhost
> > worker.ajp12.type=ajp12
> >
> > # Added for SOAP NBI
> > worker.soapnbi.port=8009
> > worker.soapnbi.host=localhost
> > worker.soapnbi.type=ajp13
> >
> > # Added for CSA - JBOSS
> > worker.csajboss.port=8011
> > worker.csajboss.host=c04s02h02IBM2
> > worker.csajboss.type=ajp13
> >
> > #// next are lb related.
> >
>
> Does this happen in an Apache httpd VirtualHost ?
> If yes, make sure that you re-read the configuration documentation at
> http://tomcat.apache.org/connectors-doc/reference/apache.html
> and in particular, the sections about JkMount and JkMountCopy.
>
>
> -
> 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
>
>


-- 
--
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de


How to comply with http://www.sitemaps.org/protocol.html#location

2016-03-14 Thread Terence M. Bandoian

On 3/13/2016 10:23 AM, Lyallex wrote:

CentOS 5.2
jdk1.7.0_45
apache-tomcat-7.0.42
no httpd, tomcat only, one webapp ROOT.war

According to the documentation at

http://www.sitemaps.org/protocol.html#location

An xml sitemap should appear in the context root, if it dosn't it can
only contain a limited set of urls.

Currently, whenever I add a new product for sale I auto generate
sitemap.xml and write it to a remote context called sitemap giving me
the sitemap URL

www.mysite.com/sitemap/sitemap.xml which I detail in robots.txt

However this is apparently incorrect and sitemap.xml should live at
www.mysite.com/sitemap.xml. Unfortunately it is not possible to write
to the root of my web app on the fly so how do people deal with this ?

Thanks
Lyallex




One solution might be to write a servlet mapped to /sitemap.xml that 
reads sitemap.xml from an alternate location and sends the contents as a 
response to any requests for /sitemap.xml


-Terence Bandoian
 http://www.tmbsw.com/


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



Re: Error 404 for autodiscover.xml

2016-03-14 Thread Olaf Kock
Welcome to the internet. I guess that you'll also find a lot of requests
for /phpmyadmin/*, /wordpress/* and a bunch of other software that you
didn't install. There's background chatter on the internet, constantly
scanning for known vulnerabilities (or just creating an index of
installed software for the time when there is a vulnerability).

Moreover, you don't state the originating IP address that's requesting
this document but ask who's doing it. You should check your access log.
If it's within your own network: Check the originator. If it's from
elsewhere on the internet: Disregard. It's 404 anyway - the correct
answer. Just like you'll find requests for /robots.txt and /favicon.ico,
even if you never reference them anywhere.

Olaf

Am 14.03.2016 um 08:18 schrieb Subhro Paul:
> From:   Mark Thomas 
> To: Tomcat Users List 
> Date:   03/11/2016 02:43 PM
> Subject:Re: Error 404 for autodiscover.xml
>
>
>
> On 11/03/2016 08:26, Subhro Paul wrote:
>> Hi All,
>>
>> Our client has a simple website consists of some jsps, images, css, 
>> javascripts and html files. It has two Apache proxy(under loadbalancers) 
>> and two Tomcat6(under Loadbalancer). All servers are installed under 
> Linux 
>> environment.This website don't deal with any e-mailing or SMTP features. 
>> It dose not have any Microsoft exchange facility(I am not sure what it 
> is. 
>> Got this things while searching in the web). It's a very simple website 
>> and all are static contents.
>>
>> But if we see the log we always see the below present in the logs in 
> both 
>> proxy and tomcat box.
>>
>> [11/Mar/2016:00:36:04 -0500] "POST /autodiscover/autodiscover.xml 
>> HTTP/1.1" 404 172
>> [11/Mar/2016:00:36:06 -0500] "GET /autodiscover/autodiscover.xml 
> HTTP/1.1" 
>> 404 172
>>
>> Why this /autodiscover/autodiscover.xml is called? Who is calling it? Is 
>> that a feature of Apache proxy which is automatically called?
>>
>> Before going to prevent this log I first want to know why is this been 
>> called?
> http://lmgtfy.com/?q=%2Fautodiscover%2Fautodiscover.xml
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
>
> Hi Mark,
> The link you have provided i have already done with that but i want to 
> know some specific reason why that autodiscover.xml is been called for my 
> application though we don't have any any e-mailing, SMTP features or 
> Microsoft exchange facility?
>
> Thanks & Regards,
> Subhro Paul
>
>
>
>
> =-=-=
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain 
> confidential or privileged information. If you are 
> not the intended recipient, any dissemination, use, 
> review, distribution, printing or copying of the 
> information contained in this e-mail message 
> and/or attachments to it are strictly prohibited. If 
> you have received this communication in error, 
> please notify us by reply e-mail or telephone and 
> immediately and permanently delete the message 
> and any attachments. Thank you
>
>
>


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



RE: [COMMERCIAL] Re: Need Help: - jk doesn't work after upgrade to 1.2.40 from 1.2.23

2016-03-14 Thread ZHAO Eric
Dear Andre,

Thanks for your response!
We didn't use Virtual Host in our setting.  I re-read the documentation and 
didn't find anything wrong with the setting, also this setting worked before. 
Do you have several minutes to check the setting in our server for mod_jk?  
Appreciate for your time.

Best Regards,
Eric.

-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com] 
Sent: Saturday, March 12, 2016 10:18 PM
To: users@tomcat.apache.org
Subject: [COMMERCIAL] Re: Need Help: - jk doesn't work after upgrade to 1.2.40 
from 1.2.23

On 12.03.2016 15:04, ZHAO Eric wrote:
> Hello,
>
> I am new to Tomcat Connectors, we are trying to upgrade the existing mod_jk 
> 1.2.23 to 1.2.40 for IPV6 configuration.
>
> But we always got the following error in jk.log with 1.2.40, we don't know if 
> anything need to adjust after upgrade to the new version:
> [Thu Mar 10 17:45:10.790 2016] [13878:140261127514080] [debug] 
> jk_translate::mod_jk.c (3855): missing uri map for 
> IBM001OAM01:/sso/lsm/lsm.jnlp [Thu Mar 10 17:45:10.790 2016] 
> [13878:140261127514080] [debug] jk_map_to_storage::mod_jk.c (4023): 
> missing uri map for IBM001OAM01:/sso/lsm/lsm.jnlp
>
> Can some one help me out from this issue? Appreciated in advance, the 
> following are the setting, we don't have uriworkermapping.properties file.
>
> Here is our setting for mod_jk:
> mod_jk.conf:
> 
>LoadModule jk_module /usr/lib64/httpd/modules/mod_jk.so
> 
>
> JkWorkersFile /etc/httpd/conf/workers.properties
> JkLogFile /var/log/jk.log
> # JkLogLevel debug
> JkLogLevel warning
>
> JkMount /MIBS ajp12
> JkMount /MIBS/* ajp12
> ...
> JkMount /sso csajboss
> JkMount /sso/* csajboss
>
>
> workers.properties:
> worker.list=ajp12,soapnbi,csajboss,csawebsso,loadbalancer,cfmaplayer1,
> cfmaplayer2,cfmaplayer3
>
> worker.ajp12.port=8007
> worker.ajp12.host=localhost
> worker.ajp12.type=ajp12
>
> # Added for SOAP NBI
> worker.soapnbi.port=8009
> worker.soapnbi.host=localhost
> worker.soapnbi.type=ajp13
>
> # Added for CSA - JBOSS
> worker.csajboss.port=8011
> worker.csajboss.host=c04s02h02IBM2
> worker.csajboss.type=ajp13
>
> #// next are lb related.
>

Does this happen in an Apache httpd VirtualHost ?
If yes, make sure that you re-read the configuration documentation at 
http://tomcat.apache.org/connectors-doc/reference/apache.html
and in particular, the sections about JkMount and JkMountCopy.


-
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: Error 404 for autodiscover.xml

2016-03-14 Thread Subhro Paul
From:   Mark Thomas 
To: Tomcat Users List 
Date:   03/11/2016 02:43 PM
Subject:Re: Error 404 for autodiscover.xml



On 11/03/2016 08:26, Subhro Paul wrote:
> Hi All,
> 
> Our client has a simple website consists of some jsps, images, css, 
> javascripts and html files. It has two Apache proxy(under loadbalancers) 

> and two Tomcat6(under Loadbalancer). All servers are installed under 
Linux 
> environment.This website don't deal with any e-mailing or SMTP features. 

> It dose not have any Microsoft exchange facility(I am not sure what it 
is. 
> Got this things while searching in the web). It's a very simple website 
> and all are static contents.
> 
> But if we see the log we always see the below present in the logs in 
both 
> proxy and tomcat box.
> 
> [11/Mar/2016:00:36:04 -0500] "POST /autodiscover/autodiscover.xml 
> HTTP/1.1" 404 172
> [11/Mar/2016:00:36:06 -0500] "GET /autodiscover/autodiscover.xml 
HTTP/1.1" 
> 404 172
> 
> Why this /autodiscover/autodiscover.xml is called? Who is calling it? Is 

> that a feature of Apache proxy which is automatically called?
> 
> Before going to prevent this log I first want to know why is this been 
> called?

http://lmgtfy.com/?q=%2Fautodiscover%2Fautodiscover.xml

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




Hi Mark,
The link you have provided i have already done with that but i want to 
know some specific reason why that autodiscover.xml is been called for my 
application though we don't have any any e-mailing, SMTP features or 
Microsoft exchange facility?

Thanks & Regards,
Subhro Paul




=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you