date:20120323

2012/3/23 Caldarale, Charles R :
>> From: Chema [mailto:demablo...@gmail.com]
>> Subject: Re: chunked encoding
>
>> But, if I'm not wrong , chunks messages belong application layer, so
>> when servers pass them to TCP/IP stack , they are different messages.
>
> TCP/IP knows nothing about "messages", only about the two byte streams for 
> the connection (one inbound, one outbound).

Thanks.
You're right . It was my fault.
If I consider to send many chunks over the same TCP connection, it has
sense for me.

I don't know why I thought on different chunks over separate connections.

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

Re: chunked encoding

>
> TCP packets are numbered (by TCP itself). Thus chunks are ordered as well.
>

So, chunks aren't sent on the same time, but they are sent by the same
TCP connection .
In this case, it has sense for me: a stream of chunks . Thanks

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

RE: chunked encoding

> From: Chema [mailto:demablo...@gmail.com] 
> Subject: Re: chunked encoding

> But, if I'm not wrong , chunks messages belong application layer, so
> when servers pass them to TCP/IP stack , they are different messages.

TCP/IP knows nothing about "messages", only about the two byte streams for the 
connection (one inbound, one outbound).

> Do it by same connection , but they are different messages on
> application layer , right ?

It's up to the application to deliver the chunks to its outbound TCP/IP stack 
in the proper order.  If you have a multi-threaded application where each 
thread has responsibility for a different chunk, it's still up to the 
application to get them to the TCP/IP stack in the correct sequence.  However, 
that is all moot, since the processing of a given request and response in a 
servlet container is single-threaded, by definition.

> I can rely on the order which messages were sent, but it doesn't look
> very reliable

It's completely reliable, unless you take overt action to write a really, 
really convoluted application on the server.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: chunked encoding

2012/3/24 Chema :
>> The server application must pass the chunks to its outbound TCP/IP stack in 
>> order, so normal TCP sequencing takes care of it.
>>
>
> Thanks
> But, if I'm not wrong , chunks messages belong application layer, so
> when servers pass them to TCP/IP stack , they are different messages.
> Do it by same connection , but they are different messages on
> application layer , right ?
>

TCP packets are numbered (by TCP itself). Thus chunks are ordered as well.

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

Re: chunked encoding

> The server application must pass the chunks to its outbound TCP/IP stack in 
> order, so normal TCP sequencing takes care of it.
>

Thanks
But, if I'm not wrong , chunks messages belong application layer, so
when servers pass them to TCP/IP stack , they are different messages.
Do it by same connection , but they are different messages on
application layer , right ?

I see it how a chat conversation: when I send "Hello" and "Bye" by
client chat  , receiver chat only can know the right order if there is
any mechanism on *application layer* to put them in order

I can rely on the order which messages were sent, but it doesn't look
very reliable

Sure I'm wrong but I don't understand it

Thanks and regards

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

Re: upgraded fedora and mod_jk will not work

2012-03-23 Thread Ray Holme

Andre - good information. Thanks but still in the weeds here.


> Depends how long Tomcat and your applications need to start up and be ready 
> to answer requests.

makes sense. since httpd is NOT coming up on boot as it should, I will make it 
second
  with a preceding sleep and background the whole thing - maybe that will fix 
it:
    (sleep 10; S96httpd start) &

  THAT WORKS fine. httpd is now up correctly after a boot. YEA!

Not surprising that it worked while being wrong, because these parameters are 
obsolete and just ignored.

:=[ (thanks)

>You don't seem to be using load balancing workers, so basically you don't care.
>But the error message may indicate that Apache httpd is not able to write that 
>file, in that location.
>Does that directory even exist ?  (logfiles usually go to somewhere like 
>/var/log/*.  /etc/hhtpd/logs is somewhat unusual.)

Thanks again. It turns out that /etc/httpd/logs is a symbolic link to 
/var/httpd/log (feel better?).
However as I did mention later in the original mail message- two files are 
created and are of size 0.
So it can write, but is not happy.
Without the new line about the shared memory in httpd.conf - httpd complained 
even more that it did not like it but would default.
Will correct the line to point directly and not use the link. (no effect, but 
makes better sense to me)

ls -l /var/log/httpd
...
-rw-r--r--. 1 root root    0 Mar 23 09:27 jk-runtime-status.3686
-rw-r--r--. 1 root root    0 Mar 23 09:27 jk-runtime-status.3690
...

I did pull the mod_jk.so release suggested 1.2.32. It also needed to be 
stripped after the install.
But it did not help - see below.

THIS IS THE CRUX OF THE PROBLEM - STILL!
>> [info] ajp_connect_to_endpoint::jk_ajp_common.c (992): Failed opening socket 
>> to (127.0.0.1:8009) (errno=13)
>> [error] ajp_send_request::jk_ajp_common.c (1621): (wrkr) connecting to 
>> backend failed. Tomcat is probably not started or is listening on the wrong 
>> port (errno=13)
>> [info] ajp_service::jk_ajp_common.c (2614): (wrkr) sending request to tomcat 
>> failed (recoverable), because of error during request sending (attempt=1)
>> [info] jk_open_socket::jk_connect.c (627): connect to 127.0.0.1:8009 failed 
>> (errno=13)


>That's probably because you start httpd before tomcat, as explained earlier.  
>Tomcat has not opened its AJP socket 8009 yet, so httpd+mod_jk cannot connect 
>to it.

You could be right, but
  a) these MESSAGES do not happen until both tomcat and httpd are up and I try 
to get to the application in a browser
  b) under prior releases of fedora (14, 12, 8) I was able to start httpd 
hugely later and it worked - no complaints
 (sometimes it came up by itself, sometimes not - I like this rc.local way 
better)

NOPE, in this case you did not hit the ball out of the park. I remain stuck 
with httpd thinking tomcat is NOT talking.
Since I have done almost nothing to configure tomcat as you noticed with ssl, I 
am baffled.

But thanks, you did solve one or two issues and explained a couple more.

RE: chunked encoding

> From: Chema [mailto:demablo...@gmail.com] 
> Subject: Re: chunked encoding

> How does web browser know what is the right order of the chunks ?

The order they are passed to the client by the client's inbound TCP/IP stack is 
the correct order.

> But when server sends response by chunks I don't know how the 
> client (web browser ) puts them in order

The server application must pass the chunks to its outbound TCP/IP stack in 
order, so normal TCP sequencing takes care of it.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: chunked encoding

> 1. http://en.wikipedia.org/wiki/Chunked_transfer_encoding
> 2. RFC 2616 (the specification of HTTP/1.1 protocol)

One question

How does web browser know what is the right order of the chunks ?
When server waits for generating the whole response, I understand that
transmission can rely on TCP and the client ( web browser ) can be
sure that response is completed and all message parts are in order

But when server sends response by chunks I don't know how the client (
web browser ) puts them in order
I did't seen anything about it on Wikipedia link

Thanks and regards

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

Re: upgraded fedora and mod_jk will not work

2012-03-23 Thread Ray Holme



> (had to strip final binary to make it work at all - not mentioned)

What do you mean?

I mean that the built binary was NOT stripped and would not work (apache 
complained about loading it - sorry I forgot the message).

I simply did "strip mod_jk.so" and the size went down by a factor of 4 and then 
it worked.

WORKED being a kind of funny word in this case. It loaded but did not work.

Re: Tomcat 7.0.x problems using LockOutRealm

2012-03-23 Thread Ed M

Hi All,

Here's my problem:

I get 403 error when using my custom realm with LockOutRealm.

My implementation works with no problems on Tomcat 6.0.x. It also works
well if I configure my realm with no *LockOutRealm *present in my
configuration.

Configuration for both versions in server.xml nested in :

  
 

  

I have found is that AuthenticatorBase.java realm returned within
*invoke *method
from *this.context.getRealm()* (line 464 in version 7.0.25) in the
beginning it returns my ConsoleRealm. Later this method is invoked during
same login process again I get LockOutRealm returned. And when RealmBase.*
hasRole *executed it gives returns false which gives 403 http error.

For me it seems like configuration issue, but was unable to find answer in
the documentation.

Would anyone be able to help me?

Thanks,

Ed

Re: upgraded fedora and mod_jk will not work


Note : you /do/ get bonus points for providing the versions of what you're 
using.
Not everyone does that.

And you also got an immediate reward, in the form of Chuck's and Konstantin's warnings 
about your mod_jk version (which could have caused you severe problems later, had you not 
mentioned it).



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

Re: upgraded fedora and mod_jk will not work

Ray Holme wrote:

I have recently upgraded from Fedora 14 to Fedora 16. I am testing 4 tomcat
applications on the local web (and one plain apache app.) on one box (no other
tricks like multiple servers ...). The below should pretty well describe
everything I think matters.

I was running Tomcat 6.0.29 and then 6.0.35 on Fedora 14 and am now trying the
latter on 16 - there were no changes in the apache-tomcat directory for the new
release (NONE _ just restored it and tomcat comes up with it's normal chatter).
Nut my release is pretty vanilla - after unpacking the gzip'd tomcat tar file I
added the 4 webapps; the .xml files for each under conf/Catalina ... and added
the DB driver .jar to the lib directory (symbolic linked) - then it worked fine
(under fedora 14)

I downloaded and built the newest mod_jk.so (tomcat-connectors-1.2.33) from src
(had to strip final binary to make it work at all - not mentioned). I still
have the old one if need be and yes I tried it too.

I installed the mod_jk.so in /usr/lib64/httpd/modules with the rest of them
(the Apache mod_jk online docs seems a little old here but were helpful).

I modified the workers.properties (removed cache stuff which apache complained
of as dead). Here is what I have left:

---
# workers.properties - ajp13
workers.tomcat_home=/opt/apache <-- obsolete, delete line
workers.java_home=/usr/java/jdk <-- obsolete, delete line
ps=/ <- maybe obsolete too, don't remember
#
# List workers
worker.list=wrkr
#
# Define wrkr
worker.wrkr.port=8009
worker.wrkr.host=localhost
worker.wrkr.type=ajp13
worker.wrkr.socket_timeout=300 <-- I wouldn't do that, unless you have a
specific reason to specify this.

---

I have an /etc/rc.d/rc.local file which should bring up httpd, THEN tomcat. Tomcat comes
up fine (the logs look fine), but httpd never comes up till I manually run the same
script after login. I know the script ran from boot time but it leaves NO complaints as I
added an echo line to it and a "clean" script for /etc/httpd/logs which did
definitely run (until I am up, I want fresh error files, maybe even after that).

Not sure I understand all of that, but it doesn't seem to be a Tomcat problem.
You should try to find out why httpd doesn't start when run from the boot script during
boot. Maybe you are trying to access something that the boot environment doesn't have
yet, but that is available later when you run it by hand ? (like some filesystem which
only gets mounted later on ?)

Question 1: is the order right? (httpd then tomcat)
or should I bring up tomcat before httpd??

Probably better tomcat first. Otherwise, if a request comes in, Apache+mod_jk will try to
connect to tomcat, tomcat won't be there yet, and you'll get errors.

pause between?

Depends how long Tomcat and your applications need to start up and be ready to answer
requests.

1.1 - is the java home right or should it be /usr/java?
- these were both dead wrong under fedora 14 (and it worked)
as it pointed to /usr/java/jdk1.6.something and I have
/usr/java/jdk1.7..
and the tomcat_home was wrong too. They are correct now (both
are symbolic links
to the real place so I don't do that again).

Not surprising that it worked while being wrong, because these parameters are obsolete and
just ignored.

I have carefully modified the http.conf file to be identical to what I had
before with identical lines about worker properties. For the sake of
completeness - here are the mods to the orginal httpd.conf (minus the comment
lines) - I had to add a JkShmFile line to my old conf file to remove one
startup complaint from the newer httpd mod_jk.

Listen 192.168.101.101:80
...
LoadModule jk_module modules/mod_jk.so
JkWorkersFi

le /etc/httpd/conf/workers.properties

JkLogFile /var/log/httpd/mod_jk.log
JkLogLevel info
JkShmFile /etc/httpd/logs/jk.shm
JkLogStampFormat "[%a %b %d %H:%M:%S %Y]
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories

JkRequestLogFormat "%w %V %T"
JkMount /ledger wrkr
JkMount /ledger/* wrkr
### 3 other app line sets like the above 2 lines are cut for brevity

So I start httpd manually now and it says "OK", but the log files do not say
this. Here are the log messages (without the leading dates) and cutting duplicates

error_log ->
[notice] mod_python: Creating 4 session mutexes based on 256 max processes and
0 max threads.

Question 2: I suspect this might be OK (in earlier fedora too), why "0" max?
- zero is small, is this a problem at all?

Don't know. That's something you should ask the "mod_python" guys.

ssl_error_log->
[warn] RSA server certificate CommonName (CN) `localhost.localdomain' does NOT
match server name!?

Question 3: Also seen in earlier ssl_error_logs, but I am

Re: upgraded fedora and mod_jk will not work

2012/3/23 Ray Holme :
> I downloaded and built the newest mod_jk.so (tomcat-connectors-1.2.33) from 
> src (had to strip final binary to make it work at all - not mentioned). I 
> still have the old one if need be and yes I tried it too.

1.2.33 is known to be broken and causes core in httpd in certain configurations.

The voting for 1.2.35 is currently in progress - you can find download
link in the VOTE thread on the dev@ list if you wanna give it a try.


> (had to strip final binary to make it work at all - not mentioned)

What do you mean?

>
> Question 1: is the order right? (httpd then tomcat)
>     or should I bring up tomcat before httpd??
>     pause between?

It should work either way.

Best regards,
Konstantin Kolinko

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

Re: configuring SSL for Tomcat with .pfx

2012-03-23 Thread Daniel Mikusa

- Original Message -
> Hi everyone,
> 
> I have been tasked with configuring SSL for Tomcat. I am new to
> Tomcat configuration so I have been through the docs and consulted
> many different articles in an attempt to figure out how all of this
> works.
> 
> I have been given the following (attached):
> 
> * Thawte Primary Root CA.cer
> 
> * Thawte SSL CA.cer
> 
> * remedy.optinet.net_cert.pfx
> 
> My plan was to import the root cert then the intermediate cert then
> the .pfx by doing the following:
> 
> 
> * keytool -import -keystore tomcat.keystore2 -storepass
> password -storetype PKCS12 -file "c:\Thawte Primary Root CA.cer"
> 
> * keytool -import -keystore tomcat.keystore2 -storepass
> password -storetype PKCS12 -file c:\Thawte SSL CA.cer
> 
> * keytool -importkeystore -deststorepass password
> -destkeystore c:\tomcat.keystore2 -srckeystore
> c:\remedy.optinet.net_cert.pfx -srcstoretype PKCS12 -srcstorepass
> password
> 


What if you try this...

1.) Import your existing PKCS12 keystore into a Java Keystore.

keytool -importkeystore -srckeystore remedy.optinet.net_cert.pfx -srcstoretype 
pkcs12 -srcstorepass password -destkeystore remedy.optinet.net_cert.jks 
-deststoretype jks -deststorepass password

2.) Then import your root and intermediate certificates into the 
remedy.optinet.net_cert.jks.


Alternatively, you might try a GUI utility like Keystore Explorer.

http://www.lazgosoftware.com/kse/index.html

Dan


> But got the following error when I started with the root cert:
> 
> D:\Program Files (x86)\Java\jdk1.6.0_19\bin>keytool -import -keystore
> tomcat.keystore2 -storepass password -file "c:\Thawte Primary Root
> CA.cer"
> keytool error: java.lang.Exception: Input not an X.509 certificate
> 
> 
> Then I imported the certificates into certmgr and exported them to
> X.509 and tried again  got the following:
> 
> D:\Program Files (x86)\Java\jdk1.6.0_19\bin>keytool -import -keystore
> tomcat.key
> store2 -storepass password -storetype PKCS12 -file "Thawte Primary
> Root CA_x.cer
> "
> Owner: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For
> authorized use
> only", OU=Certification Services Division, O="thawte, Inc.", C=US
> Issuer: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For
> authorized us
> e only", OU=Certification Services Division, O="thawte, Inc.", C=US
> Serial number: 344ed55720d5edec49f42fce37db2b6d
> Valid from: Fri Nov 17 02:00:00 CAT 2006 until: Thu Jul 17 01:59:59
> CAT 2036
> Certificate fingerprints:
>  MD5:  8C:CA:DC:0B:22:CE:F5:BE:72:AC:41:1A:11:A8:D8:12
>  SHA1:
>  91:C6:D6:EE:3E:8A:C8:63:84:E5:48:C2:99:29:5C:75:6C:81:7B:81
>  Signature algorithm name: SHA1withRSA
>  Version: 3
> 
> Extensions:
> 
> #1: ObjectId: 2.5.29.15 Criticality=true
> KeyUsage [
>   Key_CertSign
>   Crl_Sign
> ]
> 
> #2: ObjectId: 2.5.29.19 Criticality=true
> BasicConstraints:[
>   CA:true
>   PathLen:2147483647
> ]
> 
> #3: ObjectId: 2.5.29.14 Criticality=false
> SubjectKeyIdentifier [
> KeyIdentifier [
> : 7B 5B 45 CF AF CE CB 7A   FD 31 92 1A 6A B6 F3 46
>  .[Ez.1..j..F
> 0010: EB 57 48 50.WHP
> ]
> ]
> 
> Trust this certificate? [no]:  yes
> keytool error: java.security.KeyStoreException: TrustedCertEntry not
> supported
> 
> I am struggling to get to grips with all of the components like the
> "alias", "key", "algorithm", "keystore", "certificate", etc ... and
> the different types of keystores ; different types of certificates
> and so many other things.
> 
> If you could assist me I would appreciate it greatly.
> 
> Regards
> Melanie Snayer
> BMC Remedy Product Consultant
> __
> Blue Turtle Technologies
> Tel : +27 (0) 87 721 1874/5/6   |   Fax:  +27 (0)21 552 7764  |
>  Cell:  +27 (0)82 568 6205
> email:   melan...@blueturtle.co.za
>   |   web:  www.blueturtle.co.za
> 
> Imagination was given to us to compensate for what we are not; a
> sense of humor was given to us to console us for what we are.
> - Mark McGinnis
> 
> 
> 
> Blue Turtle Technologies (Pty) Limited | Reg. no.: 2003/002610/07 |
> http://www.blueturtle.co.za
> Gauteng : Tel: +27 (0)11 206 5600 | Fax: +27 (0)11 206 5606 |
> Midridge Office Estate, International Business Gateway, cnr New Road
> & Sixth Street, Midrand, 1685 | P O Box 31331, Kyalami, 1684
> Western Cape: Tel: +27 (0)87 721 1874 | Fax: +27 (0)21 552 7764 |
> Unit E6, Century Square, Heron Crescent, Century City, Cape Town,
> 7446
> 
> DISCLAIMER: This email and any files transmitted with it are
> confidential and are intended solely for the use of the individual
> or entity to whom they are addressed. This communication represents
> the originator's personal views and opinions, which do not
> necessarily reflect those of Blue Turtle Technologies

RE: upgraded fedora and mod_jk will not work

> From: Ray Holme [mailto:rayho...@yahoo.com] 
> Subject: upgraded fedora and mod_jk will not work

> I downloaded and built the newest mod_jk.so (tomcat-connectors-1.2.33)

Oops - please read the headline in the docs:

"The Apache Tomcat team wishes to draw your attention to stability issues that 
have been identified with the recent mod_jk 1.2.33 release. If you have not yet 
upgraded to mod_jk 1.2.33 we recommend that you wait for the mod_jk 1.2.34 
release which is currently in progress. If you have upgraded and are 
experienced issues we recommend that you downgrade to mod_jk 1.2.32 until 
mod_jk 1.2.34 is available.

"We apologise for any inconvenience."

http://tomcat.apache.org/connectors-doc/

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

upgraded fedora and mod_jk will not work

2012-03-23 Thread Ray Holme

I have recently upgraded from Fedora 14 to Fedora 16. I am testing 4 tomcat 
applications on the local web (and one plain apache app.) on one box (no other 
tricks like multiple servers ...). The below should pretty well describe 
everything I think matters.

I was running Tomcat 6.0.29 and then 6.0.35 on Fedora 14 and am now trying the 
latter on 16 - there were no changes in the apache-tomcat directory for the new 
release (NONE _ just restored it and tomcat comes up with it's normal chatter). 
Nut my release is pretty vanilla - after unpacking the gzip'd tomcat tar file I 
added the 4 webapps; the .xml files for each under conf/Catalina ... and added 
the DB driver .jar to the lib directory (symbolic linked) - then it worked fine 
(under fedora 14)

I downloaded and built the newest mod_jk.so (tomcat-connectors-1.2.33) from src 
(had to strip final binary to make it work at all - not mentioned). I still 
have the old one if need be and yes I tried it too.

I installed the mod_jk.so in /usr/lib64/httpd/modules with the rest of them 
(the Apache mod_jk online docs seems a little old here but were helpful).

I modified the workers.properties (removed cache stuff which apache complained 
of as dead). Here is what I have left:

---
# workers.properties - ajp13
workers.tomcat_home=/opt/apache
workers.java_home=/usr/java/jdk
ps=/
#
# List workers
worker.list=wrkr
#
# Define wrkr
worker.wrkr.port=8009
worker.wrkr.host=localhost
worker.wrkr.type=ajp13
worker.wrkr.socket_timeout=300
---

I have an /etc/rc.d/rc.local file which should bring up httpd, THEN tomcat. 
Tomcat comes up fine (the logs look fine), but httpd never comes up till I 
manually run the same script after login. I know the script ran from boot time 
but it leaves NO complaints as I added an echo line to it and a "clean" script 
for /etc/httpd/logs which did definitely run (until I am up, I want fresh error 
files, maybe even after that).

Question 1: is the order right? (httpd then tomcat)
    or should I bring up tomcat before httpd??
    pause between?
 1.1 - is the java home right or should it be /usr/java?
 - these were both dead wrong under fedora 14 (and it worked)
   as it pointed to /usr/java/jdk1.6.something and I have 
/usr/java/jdk1.7..
   and the tomcat_home was wrong too. They are correct now (both 
are symbolic links
    to the real place so I don't do that again).

I have carefully modified the http.conf file to be identical to what I had 
before with identical lines about worker properties. For the sake of 
completeness - here are the mods to the orginal httpd.conf (minus the comment 
lines) - I had to add a JkShmFile line to my old conf file to remove one 
startup complaint from the newer httpd mod_jk.


Listen 192.168.101.101:80
...
LoadModule jk_module modules/mod_jk.so
JkWorkersFile /etc/httpd/conf/workers.properties
JkLogFile /var/log/httpd/mod_jk.log
JkLogLevel info
JkShmFile   /etc/httpd/logs/jk.shm
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] 
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
JkRequestLogFormat "%w %V %T"
JkMount /ledger wrkr
JkMount /ledger/* wrkr
### 3 other app line sets like the above 2 lines are cut for brevity


So I start httpd manually now and it says "OK", but the log files do not say 
this. Here are the log messages (without the leading dates) and cutting 
duplicates

error_log ->
[notice] mod_python: Creating 4 session mutexes based on 256 max processes and 
0 max threads.

Question 2: I suspect this might be OK (in earlier fedora too), why "0" max?
    - zero is small, is this a problem at all?

ssl_error_log->
[warn] RSA server certificate CommonName (CN) `localhost.localdomain' does NOT 
match server name!?

Question 3: Also seen in earlier ssl_error_logs, but I am not using SSL at all 
YET and I don't like errors. I cannot find where it is picking up 
localhost.localdomain at all. I would correct that if I knew. I have tried 
adding this alias on the line with my real hostname in /etc/hosts but that does 
no good. SO, is this a problem? Whether or not it is, can I fix it?

mod_jk.log -> THESE ARE ALL NEW TO FEDORA 16 and the real problem I think
[error] init_jk::mod_jk.c (3348): Initializing shm:/etc/httpd/logs/jk.shm.2384 
errno=13. Load balancing workers will not function properly.
...
[info] ajp_connect_to_endpoint::jk_ajp_common.c (992): Failed opening socket to 
(127.0.0.1:8009) (errno=13)
[error] ajp_send_request::jk_ajp_common.c (1621): (wrkr) connecting to backend 
failed. Tomcat is probably not started or is listening on the wrong port 
(errno=13)
[info] ajp_service::jk_ajp_common.c (2614): (wrkr) sending request to tomcat 
failed (recoverable), because of error during request sending (attempt=1)
[info] jk_open_socket::jk_connect.c (627): connect to 127.0.0.1:8

Re: partial response from non-browser clients


Serdyn du Toit wrote:

Hi,

Using Tomcat 6.0.35 I got the server up and running and could retrieve
webpages from my application perfectly - using the browser.  Now I've
written some client code of my own in Java and for one or other reason it
doesn't want to retrieve everything - it only returns a partial response
and then hangs.  Multiple attempts at returning the webpage returns the
same partial response - in other words its still a partial response but its
the exact same length as the partial responses returned by the other
attempts.


[...]

That sounds a bit like the webserver sending a "chunked" response, but the client not 
being able to deal with it and thinking it gets the whole response the first time.
(I say "sounds like", because I really don't know if the Java code you're using can deal 
with this or not).


Maybe you would benefit from having a look at the Apache HttpClient classes at 
http://hc.apache.org/



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

Re: Access Log Valve invalid requests

Leo Donahue - PLANDEVX wrote:

Tomcat 6.0.35

http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Access_Log_Valve

"Some requests may be handled by Tomcat before they are passed to a container.
These include redirects from /foo to /foo/ and the rejection of invalid requests".

What is an invalid request? If I have a deny set for a Remote Host Filter, is
that considered an invalid request attempt?

What I'm trying to do is deny a certain requestor from making a POST request to
a URL that is no longer published, yet retain the attempted request in the
access log. If I'm denying the request, should I even care to log the fact
that there are still attempts at a non-existent webapp?

The requestor makes about 200 POST requests within a few seconds everyday
around the same time for the past 4 months. They all result in HTTP 500.

Find him and shoot him.

Seriously, you should be able to log its IP address. From the IP address, you should be
able to find the domain (WHOIS), and an email address for a domain admin or better someone
responsible for spam and other nasties. If it is not in China, send them an email
indicating the problem, with an excerpt of your logs.
In my experience, in most cases (80%), it works, in the sense that the attempts stop. In
1% of cases, you might even get a polite thank you answer. (*)
If it continues, then it is usually better to filter this before it even reaches Tomcat.
A firewall or iptables (Linux) just blocking any connection from that IP will do fine, and
will not force your www server to handle that load for nothing.

Most of these things are nasty hacking programs which continuously scan a range of IP
addresses and try to break in using a range of well-known "weak" URLs. Most of those are
"trojan" programs that run on hosts that have been broken in, and are not themselves even
suspecting that they have been broken in.
It can also be a legitimate program which just has the wrong hostname or IP address to
connect to. It may be worth 5 minutes of your time to let such "normal people" know that
something is amiss, rather than letting them continue to host a trojan or have a
badly-configured application running.

(*) I would be curious to see the break-down of the other 79%. They could be nice people
who realise that one of their servers is doing something it shouldn't; or they could be
nasty people knowing that their server is doing something it shouldn't, and stopping
because they've been found out. But there is no way to know for sure.

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

Re: configuring SSL for Tomcat with .pfx

2012/3/23 Melanie Snayer :
> Hi All,
>
> I didn’t add the attachment to the previous email so here it is.
>

1. Attachments are not allowed on this mailing list.

2. Using HTML-formatted e-mails is strongly discouraged.

Use plain text.

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

Re: partial response from non-browser clients

2012/3/23 Serdyn du Toit :
> Hi,
>
> Using Tomcat 6.0.35 I got the server up and running and could retrieve
> webpages from my application perfectly - using the browser.  Now I've
> written some client code of my own in Java and for one or other reason it
> doesn't want to retrieve everything - it only returns a partial response
> and then hangs.  Multiple attempts at returning the webpage returns the
> same partial response - in other words its still a partial response but its
> the exact same length as the partial responses returned by the other
> attempts.
>
> I had the same issue in Jetty so I'm not sure what it could be, but maybe
> there is some setting on my machine (Windows Vista) that's preventing any
> non-browser connection with the webservers to work 100%?
>
> The client code was first in Jersey (jersey.java.net), then written in
> plain Java, and then using Apache HttpComponents (hc.apache.org).  All
> versions of client code hanged.

Take a thread dump to see where you code spends its time when you
think it is hanging. Is is better to take several (3) dumps with some
time interval.

See FAQ
http://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics
-> "How To: Capture a thread dump"

>  The Java code (though its 100%) is as
> follows:
>
> String jsonResponse = "";
> {
> //
> http://docs.oracle.com/javase/tutorial/networking/urls/readingWriting.html
> URLConnection urlConnection = new URL(uri).openConnection();
>        BufferedReader br = new BufferedReader(new
> InputStreamReader(urlConnection.getInputStream()));

Using InputStreamReader(stream) constructor is wrong in 90% of cases.

You should always pass an encoding as the second argument.
For JSON it is usually "UTF-8".

>        String inputLine = null;
>        while ((inputLine = br.readLine()) != null)
>    jsonResponse += inputLine;

The above is a wrong way to concatenate strings. Do not do it in a
loop. Use a StringBuilder.

If you just need the text (not the lines), I would recommend to use
reader.read(char[])

>        br.close();
> }
>
> One clue - when I changed the connector's socketBuffer (
> http://tomcat.apache.org/tomcat-5.5-doc/config/http.html) the length of the
> partial response varied.  But it still didn't return the full response.
>  And the default setting worked for the browser...so no idea what could be
> wrong...
>
> Probably not a Tomcat issue - but any suggestions on what could be causing
> this would be appreciated.
>

Best regards,
Konstantin Kolinko

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

RE: configuring SSL for Tomcat with .pfx

2012-03-23 Thread Melanie Snayer

Hi All,

I didn't add the attachment to the previous email so here it is.

Regards
Melanie

From: Melanie Snayer
Sent: 23 March 2012 06:05 PM
To: 'users@tomcat.apache.org'
Subject: configuring SSL for Tomcat with .pfx

Hi everyone,

I have been tasked with configuring SSL for Tomcat. I am new to Tomcat 
configuration so I have been through the docs and consulted many different 
articles in an attempt to figure out how all of this works.

I have been given the following (attached):

* Thawte Primary Root CA.cer

* Thawte SSL CA.cer

* remedy.optinet.net_cert.pfx

My plan was to import the root cert then the intermediate cert then the .pfx by 
doing the following:

* keytool -import -keystore tomcat.keystore2 -storepass password 
-storetype PKCS12 -file "c:\Thawte Primary Root CA.cer"

* keytool -import -keystore tomcat.keystore2 -storepass password 
-storetype PKCS12 -file c:\Thawte SSL CA.cer

* keytool -importkeystore -deststorepass password -destkeystore 
c:\tomcat.keystore2 -srckeystore c:\remedy.optinet.net_cert.pfx -srcstoretype 
PKCS12 -srcstorepass password

But got the following error when I started with the root cert:

D:\Program Files (x86)\Java\jdk1.6.0_19\bin>keytool -import -keystore 
tomcat.keystore2 -storepass password -file "c:\Thawte Primary Root CA.cer"
keytool error: java.lang.Exception: Input not an X.509 certificate

Then I imported the certificates into certmgr and exported them to X.509 and 
tried again  got the following:

D:\Program Files (x86)\Java\jdk1.6.0_19\bin>keytool -import -keystore tomcat.key
store2 -storepass password -storetype PKCS12 -file "Thawte Primary Root CA_x.cer
"
Owner: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use
only", OU=Certification Services Division, O="thawte, Inc.", C=US
Issuer: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized us
e only", OU=Certification Services Division, O="thawte, Inc.", C=US
Serial number: 344ed55720d5edec49f42fce37db2b6d
Valid from: Fri Nov 17 02:00:00 CAT 2006 until: Thu Jul 17 01:59:59 CAT 2036
Certificate fingerprints:
 MD5:  8C:CA:DC:0B:22:CE:F5:BE:72:AC:41:1A:11:A8:D8:12
 SHA1: 91:C6:D6:EE:3E:8A:C8:63:84:E5:48:C2:99:29:5C:75:6C:81:7B:81
 Signature algorithm name: SHA1withRSA
 Version: 3

Extensions:

#1: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]

#2: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
: 7B 5B 45 CF AF CE CB 7A   FD 31 92 1A 6A B6 F3 46  .[Ez.1..j..F
0010: EB 57 48 50.WHP
]
]

Trust this certificate? [no]:  yes
keytool error: java.security.KeyStoreException: TrustedCertEntry not supported

I am struggling to get to grips with all of the components like the "alias", 
"key", "algorithm", "keystore", "certificate", etc ... and the different types 
of keystores ; different types of certificates and so many other things.

If you could assist me I would appreciate it greatly.

Regards
Melanie Snayer
BMC Remedy Product Consultant
__
Blue Turtle Technologies
Tel : +27 (0) 87 721 1874/5/6   |   Fax:  +27 (0)21 552 7764  |  Cell:  +27 
(0)82 568 6205
email:   melan...@blueturtle.co.za   |   web: 
 www.blueturtle.co.za

Imagination was given to us to compensate for what we are not; a sense of humor 
was given to us to console us for what we are.
- Mark McGinnis

Blue Turtle Technologies (Pty) Limited | Reg. no.: 2003/002610/07 | 
http://www.blueturtle.co.za
Gauteng : Tel: +27 (0)11 206 5600 | Fax: +27 (0)11 206 5606 | Midridge Office 
Estate, International Business Gateway, cnr New Road & Sixth Street, Midrand, 
1685 | P O Box 31331, Kyalami, 1684
Western Cape: Tel: +27 (0)87 721 1874 | Fax: +27 (0)21 552 7764 | Unit E6, 
Century Square, Heron Crescent, Century City, Cape Town, 7446

DISCLAIMER: This email and any files transmitted with it are confidential and 
are intended solely for the use of the individual or entity to whom they are 
addressed. This communication represents the originator's personal views and 
opinions, which do not necessarily reflect those of Blue Turtle Technologies 
(Pty) Ltd. If you are not the original recipient or the person responsible for 
delivering the email to the intended recipient, be advised that you have 
received this email in error, and that any use, dissemination, forwarding, 
printing, or copying of this email is strictly prohibited. If you received this 
email in error, please immediately notify the sender. Thank you.

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

configuring SSL for Tomcat with .pfx

2012-03-23 Thread Melanie Snayer

Hi everyone,

I have been tasked with configuring SSL for Tomcat. I am new to Tomcat 
configuration so I have been through the docs and consulted many different 
articles in an attempt to figure out how all of this works.

I have been given the following (attached):

* Thawte Primary Root CA.cer

* Thawte SSL CA.cer

* remedy.optinet.net_cert.pfx

My plan was to import the root cert then the intermediate cert then the .pfx by 
doing the following:


* keytool -import -keystore tomcat.keystore2 -storepass password 
-storetype PKCS12 -file "c:\Thawte Primary Root CA.cer"

* keytool -import -keystore tomcat.keystore2 -storepass password 
-storetype PKCS12 -file c:\Thawte SSL CA.cer

* keytool -importkeystore -deststorepass password -destkeystore 
c:\tomcat.keystore2 -srckeystore c:\remedy.optinet.net_cert.pfx -srcstoretype 
PKCS12 -srcstorepass password

But got the following error when I started with the root cert:

D:\Program Files (x86)\Java\jdk1.6.0_19\bin>keytool -import -keystore 
tomcat.keystore2 -storepass password -file "c:\Thawte Primary Root CA.cer"
keytool error: java.lang.Exception: Input not an X.509 certificate


Then I imported the certificates into certmgr and exported them to X.509 and 
tried again  got the following:

D:\Program Files (x86)\Java\jdk1.6.0_19\bin>keytool -import -keystore tomcat.key
store2 -storepass password -storetype PKCS12 -file "Thawte Primary Root CA_x.cer
"
Owner: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use
only", OU=Certification Services Division, O="thawte, Inc.", C=US
Issuer: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized us
e only", OU=Certification Services Division, O="thawte, Inc.", C=US
Serial number: 344ed55720d5edec49f42fce37db2b6d
Valid from: Fri Nov 17 02:00:00 CAT 2006 until: Thu Jul 17 01:59:59 CAT 2036
Certificate fingerprints:
 MD5:  8C:CA:DC:0B:22:CE:F5:BE:72:AC:41:1A:11:A8:D8:12
 SHA1: 91:C6:D6:EE:3E:8A:C8:63:84:E5:48:C2:99:29:5C:75:6C:81:7B:81
 Signature algorithm name: SHA1withRSA
 Version: 3

Extensions:

#1: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]

#2: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
: 7B 5B 45 CF AF CE CB 7A   FD 31 92 1A 6A B6 F3 46  .[Ez.1..j..F
0010: EB 57 48 50.WHP
]
]

Trust this certificate? [no]:  yes
keytool error: java.security.KeyStoreException: TrustedCertEntry not supported

I am struggling to get to grips with all of the components like the "alias", 
"key", "algorithm", "keystore", "certificate", etc ... and the different types 
of keystores ; different types of certificates and so many other things.

If you could assist me I would appreciate it greatly.

Regards
Melanie Snayer
BMC Remedy Product Consultant
__
Blue Turtle Technologies
Tel : +27 (0) 87 721 1874/5/6   |   Fax:  +27 (0)21 552 7764  |  Cell:  +27 
(0)82 568 6205
email:   melan...@blueturtle.co.za   |   web: 
 www.blueturtle.co.za

Imagination was given to us to compensate for what we are not; a sense of humor 
was given to us to console us for what we are.
- Mark McGinnis



Blue Turtle Technologies (Pty) Limited | Reg. no.: 2003/002610/07 | 
http://www.blueturtle.co.za
Gauteng : Tel: +27 (0)11 206 5600 | Fax: +27 (0)11 206 5606 | Midridge Office 
Estate, International Business Gateway, cnr New Road & Sixth Street, Midrand, 
1685 | P O Box 31331, Kyalami, 1684
Western Cape: Tel: +27 (0)87 721 1874 | Fax: +27 (0)21 552 7764 | Unit E6, 
Century Square, Heron Crescent, Century City, Cape Town, 7446

DISCLAIMER: This email and any files transmitted with it are confidential and 
are intended solely for the use of the individual or entity to whom they are 
addressed. This communication represents the originator's personal views and 
opinions, which do not necessarily reflect those of Blue Turtle Technologies 
(Pty) Ltd. If you are not the original recipient or the person responsible for 
delivering the email to the intended recipient, be advised that you have 
received this email in error, and that any use, dissemination, forwarding, 
printing, or copying of this email is strictly prohibited. If you received this 
email in error, please immediately notify the sender. Thank you.

Re: jdbc driver location in TC 7

2012-03-23 Thread David kerber

On 3/23/2012 11:19 AM, Caldarale, Charles R wrote:

From: David kerber [mailto:dcker...@verizon.net]
Subject: jdbc driver location in TC 7

Where is the recommended location for jdbc driver jars in TC7,
when I'm using separate CATALINA_HOME and CATALINA_BASE locations?

If you look in conf/catalina.properties, you'll see the order in which the 
common loader searches directories.

If it makes a difference, I am not using tomcat's connection
pooling; it's handled in my app.

That's a critical difference.

I generally would prefer to put it in my webapp's lib directory

That is the correct location, since Tomcat is not involved.

Great; thanks for confirming.

D

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

partial response from non-browser clients

2012-03-23 Thread Serdyn du Toit

Hi,

Using Tomcat 6.0.35 I got the server up and running and could retrieve
webpages from my application perfectly - using the browser.  Now I've
written some client code of my own in Java and for one or other reason it
doesn't want to retrieve everything - it only returns a partial response
and then hangs.  Multiple attempts at returning the webpage returns the
same partial response - in other words its still a partial response but its
the exact same length as the partial responses returned by the other
attempts.

I had the same issue in Jetty so I'm not sure what it could be, but maybe
there is some setting on my machine (Windows Vista) that's preventing any
non-browser connection with the webservers to work 100%?

The client code was first in Jersey (jersey.java.net), then written in
plain Java, and then using Apache HttpComponents (hc.apache.org).  All
versions of client code hanged.  The Java code (though its 100%) is as
follows:

String jsonResponse = "";
{
//
http://docs.oracle.com/javase/tutorial/networking/urls/readingWriting.html
URLConnection urlConnection = new URL(uri).openConnection();
BufferedReader br = new BufferedReader(new
InputStreamReader(urlConnection.getInputStream()));
String inputLine = null;
while ((inputLine = br.readLine()) != null)
jsonResponse += inputLine;
br.close();
}

One clue - when I changed the connector's socketBuffer (
http://tomcat.apache.org/tomcat-5.5-doc/config/http.html) the length of the
partial response varied.  But it still didn't return the full response.
 And the default setting worked for the browser...so no idea what could be
wrong...

Probably not a Tomcat issue - but any suggestions on what could be causing
this would be appreciated.

Kind regards,
Serdyn du Toit

RE: jdbc driver location in TC 7

> From: David kerber [mailto:dcker...@verizon.net] 
> Subject: jdbc driver location in TC 7

> Where is the recommended location for jdbc driver jars in TC7,
> when I'm using separate CATALINA_HOME and CATALINA_BASE locations?

If you look in conf/catalina.properties, you'll see the order in which the 
common loader searches directories.

> If it makes a difference, I am not using tomcat's connection 
> pooling; it's handled in my app.

That's a critical difference.

> I generally would prefer to put it in my webapp's lib directory

That is the correct location, since Tomcat is not involved.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: Access Log Valve invalid requests