Re: GoDaddy SSL certificate not working with Tomcat9
Follow-up to this thread: I found the problem, which was my own mistake. I failed to enter the correct domain name when creating the keystone. After going back through the entire process again, with the correct domain name, the server is up and running again. Thanks, nevertheless, for the help. Ralph > On Mar 21, 2023, at 6:38 AM, Ralph Grove wrote: > >>> I set up the server last year and installed the SSL certificate with no >>> problem. This year, after the original certificate expired, I downloaded >>> the new certificate provided by GoDaddy, removed the old certificate files >>> from the keystore, and installed the new ones. Now Tomcat is throwing a >>> "java.io.IOException: jsse.alias_no_key_entry" exception when it tries to >>> open the HTTPS connector. I also tried rebuilding the keystore from scratch >>> and requesting a new certificate, but am getting the same exception with >>> that certificate. >>> These are the commands I used to obtain and install the certificate: >>> sudo keytool -genkey -alias tomcat -keyalg RSA -keystore keystore.jks >>> sudo keytool -certreq -keyalg RSA -alias tomcat -file certreq.csr -keystore >>> keystore.jks >>> (--request and obtain certificate files from GoDaddy--) >> >> Did you run the commands below on the same keystore file you created in the >> first command above? > > Yes - it was the same file. I went through the commands twice, just to be > sure. >> >>> sudo keytool -import -alias root -keystore keystore.jks -trustcacerts -file >>> gdcerts/gdroot-g2.crt >>> sudo keytool -import -alias inter -keystore keystore.jks -trustcacerts >>> -file gdcerts/gd_bundle-g2-g1.crt >>> sudo keytool -import -alias tomcat -keystore keystore.jks -file >>> gdcerts/.crt >> >> What is the output of: >> keytool -list -v -keystore keystore.jks > > > sudo keytool -list -v -keystore keystore.jks...
Re: GoDaddy SSL certificate not working with Tomcat9
> On Mar 21, 2023, at 4:25 AM, Mark Thomas wrote: > > On 21/03/2023 01:09, Ralph Grove wrote: >> I'm having a problem installing a new SSL certificate on a GoDaddy-hosted >> server running Tomcat. Any suggestions for resolving it would be appreciated. >> I set up the server last year and installed the SSL certificate with no >> problem. This year, after the original certificate expired, I downloaded the >> new certificate provided by GoDaddy, removed the old certificate files from >> the keystore, and installed the new ones. Now Tomcat is throwing a >> "java.io.IOException: jsse.alias_no_key_entry" exception when it tries to >> open the HTTPS connector. I also tried rebuilding the keystore from scratch >> and requesting a new certificate, but am getting the same exception with >> that certificate. >> These are the commands I used to obtain and install the certificate: >> sudo keytool -genkey -alias tomcat -keyalg RSA -keystore keystore.jks >> sudo keytool -certreq -keyalg RSA -alias tomcat -file certreq.csr -keystore >> keystore.jks >> (--request and obtain certificate files from GoDaddy--) > > Did you run the commands below on the same keystore file you created in the > first command above? Yes - it was the same file. I went through the commands twice, just to be sure. > >> sudo keytool -import -alias root -keystore keystore.jks -trustcacerts -file >> gdcerts/gdroot-g2.crt >> sudo keytool -import -alias inter -keystore keystore.jks -trustcacerts -file >> gdcerts/gd_bundle-g2-g1.crt >> sudo keytool -import -alias tomcat -keystore keystore.jks -file >> gdcerts/.crt > > What is the output of: > keytool -list -v -keystore keystore.jks > sudo keytool -list -v -keystore keystore.jks Enter keystore password: Keystore type: PKCS12 Keystore provider: SUN Your keystore contains 3 entries Alias name: inter Creation date: Mar 21, 2023 Entry type: trustedCertEntry Owner: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US Issuer: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US Serial number: 7 Valid from: Tue May 03 03:00:00 EDT 2011 until: Sat May 03 03:00:00 EDT 2031 Certificate fingerprints: SHA1: 27:AC:93:69:FA:F2:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8 SHA256: 97:3A:41:27:6F:FD:01:E0:27:A2:AA:D4:9E:34:C3:78:46:D3:E9:76:FF:6A:62:0B:67:12:E3:38:32:04:1A:A6 Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false AuthorityInfoAccess [ [ accessMethod: ocsp accessLocation: URIName: http://ocsp.godaddy.com/ ] ] #2: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ : 3A 9A 85 07 10 67 28 B6 EF F6 BD 05 41 6E 20 C1 :g(.An . 0010: 94 DA 0F DE ] ] #3: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen:2147483647 ] #4: ObjectId: 2.5.29.31 Criticality=false CRLDistributionPoints [ [DistributionPoint: [URIName: http://crl.godaddy.com/gdroot-g2.crl] ]] #5: ObjectId: 2.5.29.32 Criticality=false CertificatePolicies [ [CertificatePolicyId: [2.5.29.32.0] [PolicyQualifierInfo: [ qualifierID: 1.3.6.1.5.5.7.2.1 qualifier: : 16 25 68 74 74 70 73 3A 2F 2F 63 65 72 74 73 2E .%https://certs. 0010: 67 6F 64 61 64 64 79 2E 63 6F 6D 2F 72 65 70 6F godaddy.com/repo 0020: 73 69 74 6F 72 79 2F sitory/ ]] ] ] #6: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ Key_CertSign Crl_Sign ] #7: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ : 40 C2 BD 27 8E CC 34 83 30 A2 33 D7 FB 6C B3 F0 @..'..4.0.3..l.. 0010: B4 2C 80 CE.,.. ] ] *** *** Alias name: root Creation date: Mar 21, 2023 Entry type: trustedCertEntry Owner: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US Issuer: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US Serial number: 0 Valid from: Mon Aug 31 20:00:00 EDT 2009 until: Thu Dec 31 18:59:59 EST 2037 Certificate fingerprints: SHA1: 47:BE:AB:C9:22:EA:E8:0E:78:78:34:62:A7:9F:45:C2:54:FD:E6:8B SHA256: 45:14:0B:32:47:EB:9C:C8:C5:B4:F0:D7:B5:30:91:F7:32:92:08:9E:6E:5A:63:E2:74:9D:D3:AC:A9:19:8E:DA Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.19 Criticality=true BasicConst
GoDaddy SSL certificate not working with Tomcat9
I'm having a problem installing a new SSL certificate on a GoDaddy-hosted server running Tomcat. Any suggestions for resolving it would be appreciated. I set up the server last year and installed the SSL certificate with no problem. This year, after the original certificate expired, I downloaded the new certificate provided by GoDaddy, removed the old certificate files from the keystore, and installed the new ones. Now Tomcat is throwing a "java.io.IOException: jsse.alias_no_key_entry" exception when it tries to open the HTTPS connector. I also tried rebuilding the keystore from scratch and requesting a new certificate, but am getting the same exception with that certificate. These are the commands I used to obtain and install the certificate: sudo keytool -genkey -alias tomcat -keyalg RSA -keystore keystore.jks sudo keytool -certreq -keyalg RSA -alias tomcat -file certreq.csr -keystore keystore.jks (--request and obtain certificate files from GoDaddy--) sudo keytool -import -alias root -keystore keystore.jks -trustcacerts -file gdcerts/gdroot-g2.crt sudo keytool -import -alias inter -keystore keystore.jks -trustcacerts -file gdcerts/gd_bundle-g2-g1.crt sudo keytool -import -alias tomcat -keystore keystore.jks -file gdcerts/.crt And this is the Tomcat configuration for the connector:
RE: allowHostHeaderMismatch option only works if the Host Header has an http or https prefix
Hi Chris, I suspect that if we were to take the time to set up a proxy, according to RFC7230, we would be able to get the absolute-form to reach the Tomcat code and in that case, based on reading the AbostractHttp11Processor class, I suspect the allowHostHeaderMismatch will kick in and will behave correctly. So I doubt that there is a bug to report at this stage, at least not from my observation. However, I wonder what all of this means. Could it be that the Host header injection or Host header attack issue can only occur when absolute-form is used, i.e. mostly when proxies are set up? Both you and Mark stated that with origin-form there is nothing to compare the Host header to, which makes sense. Any thoughts on this assessment? Thanks, Ralph -Original Message- From: Christopher Schultz Sent: Friday, May 27, 2022 4:26 PM To: users@tomcat.apache.org Subject: Re: allowHostHeaderMismatch option only works if the Host Header has an http or https prefix WARNING: This email originated from outside of CallMiner. Do not click any links or open any attachments unless you recognize the sender and know that the content is safe. Please report suspicious emails to: reportsuspiciousema...@callminer.com <mailto:reportsuspiciousema...@callminer.com> Mark, On 5/27/22 3:13 AM, Mark Thomas wrote: > On 27/05/2022 02:00, Ralph Atallah wrote: >> Hi Mark, >> >> Thanks again for the prompt response. >> >> You wrote below: "If the original request only has a Host header, >> then allowHostHeaderMismatch="false" isn't going to do anything >> because there is no mismatch.". I am not clear on what this means. >> What should the match be between? I thought the comparison for the >> match was between the URL's hostname, i.e. "example.com" in the >> http://example.com/myapp URL, and the Host header value which is >> "attacker.com". If that understanding is incorrect, please point me >> in the right direction of what it should be. > > The check is that the host in the request URI (if present) is > consistent with the Host header. Nothing more, nothing less. > > HTTP requests may or may not include the host in the request URI. > > The host named in the the headers of an HTTP request is completely > independent of the host name used to establish the connection to the > web server. > >> The AbstractHttp11Processor class does not get to the >> allowHostHeaderMismatch detection code because the uriBC (URI >> ByteChunk) that it reads is expecting an absolute URL >> (http://example.com/myapp), but instead, it is getting a relative one >> /myapp. The reason I say the code expects an absolute URL is because >> it checks for and "http" string at the beginning. This makes me >> wonder whether there is a setting that controls that URI format, >> absolute or relative. > > Your understanding of the HTTP protocol is flawed. You may wish to > read RFC 7230. Specifically: > > https://datatracker.ietf.org/doc/html/rfc7230#section-3.1.1 > and > https://datatracker.ietf.org/doc/html/rfc7230#section-5.3 > > Requests with the URI in origin-form do not include a host in the URI. > > The purpose of allowHostHeaderMismatch is to ensure that when the > request URI is in absolute-form that the request URI is consistent > with the Host header. > >> Regarding the addition of a filter that you propose, we have an >> existing one in our application, but by the time it is reached, the >> URL that we see is already http://attacker.com/myapp, i.e. already >> "redirected". > > There has been no redirect. The URI reported is a combination of the > Host header and request URI received. > >> Technically we could check there against a whitelist, but this would >> make the solution less out-of-the box, and more needy of user >> configuration in our app. We prefer an out-of-the-box secure solution. >> >> Any thoughts on the above? > > What you want isn't possible. Actually, I think what Ralph is requesting is exactly what Tomcat is providing in the form of allowHostHeaderMismatch (when set to false). The only problem is that Ralph is saying it's not working because the URI in the request doesn't contain a hostname *at all* (because it's optional). So there is nothing to check. Browsers don't bother to send the optional protocol/hostname/port/etc and instead send the relative URI -- relative to the Host header (no coincidentally). If you (Ralph) can reproduce this with wc or telnet where you can force the URI to be absolute *and* provide a conflicting Host header, then I think you have grounds for a bug report. > If you want request
RE: allowHostHeaderMismatch option only works if the Host Header has an http or https prefix
Hi Mark, Thank you for your help. It took some digging to fully understand the nuances in your answers below. Here are some pointers to anyone who experiences the same issue in the future and to whom these pointers might be helpful. 1. Although I had previously visited the link to the RFC7230 page https://datatracker.ietf.org/doc/html/rfc7230#section-5.3 re-reading more closely and with Mark's emphasis on it highlighted the fact that most of the time, the request line will be of the origin-form, while the absolute-form will be mainly observed when proxies are used. This was a very important explanation of why we never saw the absolute-form reach the AbstractHttp11Processor code in our test environment. 2. "The approach requiring the minimal input from the app and where the container does most of the work is the one where you define a Host element in server.xml with the name and optional aliases for the host names that are acceptable and configure the default host (that handles all requests to other hosts) to reject all other requests." This statement was key to the solution: Our server.xml looked like this: ... We simply had to change the defaultHost value to something else than "localhost", i.e. a value that will be rejected (e.g. "defaulthost"). The Host's name as well as any Aliases defined within that tag would be the only hosts accepted, whether in the URL request or in the Host header request. The rejection would respond with a 404 Not Found error. Thanks, Ralph -Original Message- From: Mark Thomas Sent: Friday, May 27, 2022 3:13 AM To: users@tomcat.apache.org Subject: Re: allowHostHeaderMismatch option only works if the Host Header has an http or https prefix WARNING: This email originated from outside of CallMiner. Do not click any links or open any attachments unless you recognize the sender and know that the content is safe. Please report suspicious emails to: reportsuspiciousema...@callminer.com <mailto:reportsuspiciousema...@callminer.com> On 27/05/2022 02:00, Ralph Atallah wrote: > Hi Mark, > > Thanks again for the prompt response. > > You wrote below: "If the original request only has a Host header, then > allowHostHeaderMismatch="false" isn't going to do anything because there is > no mismatch.". I am not clear on what this means. What should the match be > between? I thought the comparison for the match was between the URL's > hostname, i.e. "example.com" in the http://example.com/myapp URL, and the > Host header value which is "attacker.com". If that understanding is > incorrect, please point me in the right direction of what it should be. The check is that the host in the request URI (if present) is consistent with the Host header. Nothing more, nothing less. HTTP requests may or may not include the host in the request URI. The host named in the the headers of an HTTP request is completely independent of the host name used to establish the connection to the web server. > The AbstractHttp11Processor class does not get to the allowHostHeaderMismatch > detection code because the uriBC (URI ByteChunk) that it reads is expecting > an absolute URL (http://example.com/myapp), but instead, it is getting a > relative one /myapp. The reason I say the code expects an absolute URL is > because it checks for and "http" string at the beginning. This makes me > wonder whether there is a setting that controls that URI format, absolute or > relative. Your understanding of the HTTP protocol is flawed. You may wish to read RFC 7230. Specifically: https://datatracker.ietf.org/doc/html/rfc7230#section-3.1.1 and https://datatracker.ietf.org/doc/html/rfc7230#section-5.3 Requests with the URI in origin-form do not include a host in the URI. The purpose of allowHostHeaderMismatch is to ensure that when the request URI is in absolute-form that the request URI is consistent with the Host header. > Regarding the addition of a filter that you propose, we have an existing one > in our application, but by the time it is reached, the URL that we see is > already http://attacker.com/myapp, i.e. already "redirected". There has been no redirect. The URI reported is a combination of the Host header and request URI received. > Technically we could check there against a whitelist, but this would make > the solution less out-of-the box, and more needy of user configuration in our > app. We prefer an out-of-the-box secure solution. > > Any thoughts on the above? What you want isn't possible. If you want requests to be rejected unless the Host header is on a user defined allow list (presumably the set of DNS names defined for the host), then you are going to have to provide a means for the user to provide that configuration.
RE: allowHostHeaderMismatch option only works if the Host Header has an http or https prefix
Hi Mark,
Thanks again for the prompt response.
You wrote below: "If the original request only has a Host header, then
allowHostHeaderMismatch="false" isn't going to do anything because there is no
mismatch.". I am not clear on what this means. What should the match be
between? I thought the comparison for the match was between the URL's
hostname, i.e. "example.com" in the http://example.com/myapp URL, and the Host
header value which is "attacker.com". If that understanding is incorrect,
please point me in the right direction of what it should be.
The AbstractHttp11Processor class does not get to the allowHostHeaderMismatch
detection code because the uriBC (URI ByteChunk) that it reads is expecting an
absolute URL (http://example.com/myapp), but instead, it is getting a relative
one /myapp. The reason I say the code expects an absolute URL is because it
checks for and "http" string at the beginning. This makes me wonder whether
there is a setting that controls that URI format, absolute or relative.
Regarding the addition of a filter that you propose, we have an existing one in
our application, but by the time it is reached, the URL that we see is already
http://attacker.com/myapp, i.e. already "redirected". Technically we could
check there against a whitelist, but this would make the solution less
out-of-the box, and more needy of user configuration in our app. We prefer an
out-of-the-box secure solution.
Any thoughts on the above?
Thanks,
Ralph
-Original Message-
From: Mark Thomas
Sent: Thursday, May 26, 2022 12:21 PM
To: users@tomcat.apache.org
Subject: Re: allowHostHeaderMismatch option only works if the Host Header has
an http or https prefix
WARNING: This email originated from outside of CallMiner. Do not click any
links or open any attachments unless you recognize the sender and know that the
content is safe. Please report suspicious emails to:
reportsuspiciousema...@callminer.com
<mailto:reportsuspiciousema...@callminer.com>
On 26/05/2022 14:29, Ralph Atallah wrote:
> Hi Mark,
>
> What we are trying to do is to prevent Host header attacks by ensuring that
> the host name in the http request URL always matches the "Host" header in the
> request. If it does not, we are supposed refuse the request and respond with
> 400 Bad Request as per OWASP recommendations. Here are some examples:
>
> Normal request
> GET http://example.com/myapp
> Host: example.com
> Expected response: 200 OK
>
> Request with a host header attack
> GET http://example.com/myapp
> Host: attacker.com
> Expected response: 400 Bad Request
>
> The AbstracktHttp11Processor.java class seems to be doing exactly that in the
> code snippet below:
>
> if (allowHostHeaderMismatch) {
> // The requirements of RFC 2616 are being
> // applied. If the host header and the request
> // line do not agree, the request line takes
> // precedence
> hostValueMB = headers.setValue("host");
> hostValueMB.setBytes(uriB, uriBCStart + pos, slashPos - pos);
> } else {
>// The requirements of RFC 7230 are being
>// applied. If the host header and the request
>// line do not agree, trigger a 400 response.
>badRequest("http11processor.request.inconsistentHosts");
> }
>
> However, this portion of the code is never reached for the reason mentioned
> in the previous email.
>
> By the time the request reaches our application, the
> HttpServletRequest.getRequestURL() returns http://attacker.com/myapp instead
> of http://example.com/myapp
> We have enabled the AccessLogValve in server.xml in the hope to see the URL
> that reaches tomcat, but it seems that we only get the relative URL there,
> never the absolute one, i.e. we only see /myapp when we print %u for example.
>
> Any tips in this area would be much appreciated.
If the original request only has a Host header, then
allowHostHeaderMismatch="false" isn't going to do anything because there
is no mismatch.
If you want to reject requests that have a Host header that isn't one
you recognize then there are multiple options:
- write a Filter
- write a Valve
- configure a Host (or several) for the requests you want to allow and
deploy an ROOT to the default host that rejects everything else.
Mark
> Ralph
>
> -Original Message-
> From: Mark Thomas
> Sent: Thursday, May 26, 2022 3:24 AM
> To: users@tomcat.apache.org
> Subject: Re: allowHostHeaderMismatch option only works if the Host Header has
> an http or https prefix
>
> WARNING: This email originated from outside of CallMiner. Do not click any
> lin
RE: allowHostHeaderMismatch option only works if the Host Header has an http or https prefix
Hi Mark,
What we are trying to do is to prevent Host header attacks by ensuring that the
host name in the http request URL always matches the "Host" header in the
request. If it does not, we are supposed refuse the request and respond with
400 Bad Request as per OWASP recommendations. Here are some examples:
Normal request
GET http://example.com/myapp
Host: example.com
Expected response: 200 OK
Request with a host header attack
GET http://example.com/myapp
Host: attacker.com
Expected response: 400 Bad Request
The AbstracktHttp11Processor.java class seems to be doing exactly that in the
code snippet below:
if (allowHostHeaderMismatch) {
// The requirements of RFC 2616 are being
// applied. If the host header and the request
// line do not agree, the request line takes
// precedence
hostValueMB = headers.setValue("host");
hostValueMB.setBytes(uriB, uriBCStart + pos, slashPos - pos);
} else {
// The requirements of RFC 7230 are being
// applied. If the host header and the request
// line do not agree, trigger a 400 response.
badRequest("http11processor.request.inconsistentHosts");
}
However, this portion of the code is never reached for the reason mentioned in
the previous email.
By the time the request reaches our application, the
HttpServletRequest.getRequestURL() returns http://attacker.com/myapp instead
of http://example.com/myapp
We have enabled the AccessLogValve in server.xml in the hope to see the URL
that reaches tomcat, but it seems that we only get the relative URL there,
never the absolute one, i.e. we only see /myapp when we print %u for example.
Any tips in this area would be much appreciated.
Ralph
-Original Message-
From: Mark Thomas
Sent: Thursday, May 26, 2022 3:24 AM
To: users@tomcat.apache.org
Subject: Re: allowHostHeaderMismatch option only works if the Host Header has
an http or https prefix
WARNING: This email originated from outside of CallMiner. Do not click any
links or open any attachments unless you recognize the sender and know that the
content is safe. Please report suspicious emails to:
reportsuspiciousema...@callminer.com
<mailto:reportsuspiciousema...@callminer.com>
On 26/05/2022 02:20, Ralph Atallah wrote:
> Hi,
>
> We use Tomcat 7.0.109 and Tomcat 8.5 in our Tomcat based webapp deployments
> and we have a new requirement to prevent Host Header injection. The
> allowHostHeaderMismatch option seems the perfect answer to this issue.
> However, configuring it in our environment, i.e. in the server.xml connector
> tag still does not seem to make it work.
>
> Debugging the code, we see that the check for this setting is never even
> reached in the
> org.apache.coyote.http11.AbstractHttp11Processor.prepareRequest() method.
> The reason is in the code snippet below:
>
> ByteChunk uriBC = request.requestURI().getByteChunk();
> byte[] uriB = uriBC.getBytes();
> if (uriBC.startsWithIgnoreCase("http", 0)) {
> ...
> if (allowHostHeaderMismatch) {
> ...
> }
> }
>
> uriBC does not contain the full URL such as http://localhost:8080/myapp, but
> rather only the /myapp path, so that if (uriBC.startsWithIgnoreCase("http",
> 0)) condition is never met.
>
> We are probably missing something very basic, and would really appreciate
> some guidance.
I suspect that allowHostHeaderMismatch doesn't do what you think it does.
Exactly what problem are you trying to solve when so say you want to prevent
"Host header injection"?
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
allowHostHeaderMismatch option only works if the Host Header has an http or https prefix
Hi,
We use Tomcat 7.0.109 and Tomcat 8.5 in our Tomcat based webapp deployments and
we have a new requirement to prevent Host Header injection. The
allowHostHeaderMismatch option seems the perfect answer to this issue.
However, configuring it in our environment, i.e. in the server.xml connector
tag still does not seem to make it work.
Debugging the code, we see that the check for this setting is never even
reached in the
org.apache.coyote.http11.AbstractHttp11Processor.prepareRequest() method. The
reason is in the code snippet below:
ByteChunk uriBC = request.requestURI().getByteChunk();
byte[] uriB = uriBC.getBytes();
if (uriBC.startsWithIgnoreCase("http", 0)) {
...
if (allowHostHeaderMismatch) {
...
}
}
uriBC does not contain the full URL such as http://localhost:8080/myapp, but
rather only the /myapp path, so that if (uriBC.startsWithIgnoreCase("http", 0))
condition is never met.
We are probably missing something very basic, and would really appreciate some
guidance.
Thanks,
Ralph Atallah
Re: Tomcat 9 & Port 80
Sure. Here's what worked for me. As I mentioned in my original post, this is an Ubuntu 16.04 server with OpenJDK 11 installed and the Apache Tomcat 9.0.21 binary installation. I compiled the JSVC and created a setenv.sh file with some environmental variables. Tested starting Tomcat with daemon.sh and it came up on 8080. Now to get it to work on port 80: Install authbind and configure it o sudo apt install authbind o sudo touch /etc/authbind/byport/80 o sudo chmod 500 /etc/authbind/byport/80 o sudo chown tomcat /etc/authbind/byport/80 (this assumes you're running Tomcat as user tomcat) Edit server.xml to change the connector port from 8080 to 80 (make sure Tomcat isn’t running before editing) Now you should be able to start Tomcat with authbind as the tomcat user o sudo su - tomcat o authbind -deep /usr/local/apache-tomcat-9.0.21/bin/daemon.sh start (note your path will vary depending on version of Tomcat and where you installed it) If you're using a systemd script to manage the service, edit the ExecStart command to include authbind. This is the simple script I use, but there are others out there: [Unit] Description=Apache Tomcat Web Application Container After=network.target [Service] Type=forking Environment=CATALINA_PID=/usr/local/apache-tomcat-9.0.21/logs/catalina-daemon.pid Environment=CATALINA_HOME=/usr/local/apache-tomcat-9.0.21 ExecStart=/usr/bin/authbind --deep /usr/local/apache-tomcat-9.0.21/bin/daemon.sh start User=tomcat Group=tomcat [Install] WantedBy=multi-user.target If you want to run Tomcat via HTTPS you can do the same thing, just touch the file 443 in /etc/authbind/byport. Thanks, Ralph On 7/12/19, 4:40 PM, "Christopher Schultz" wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André and Ralph, On 7/12/19 05:59, André Warnier (tomcat) wrote: > On 11.07.2019 21:37, Arbelo, Ralph wrote: >> Thank you for your reply, André. >> >> Unfortunately, the Tomcat 9 Ubuntu package is only available on >> Ubuntu 18 and 19 (at least that I could find). I'm on 16 at the >> moment (though I did think about upgrading) which is why I'm >> using the binary distribution from tomcat.apache.org. >> >> The good news is I was able to get authbind to work. If anyone >> is interested in the steps I used, please let me know. >> > > Yes, of course. The fact of posting this to the mailing list, may > help someone else later resolve a similar issue more quickly. .. if > they search the mailing list archive first, of course. Sounds like a good thing to add to the Wiki, too. - -chris >> Thanks again, Ralph >> >> >> >> On 7/10/19, 5:29 AM, "André Warnier (tomcat)" >> wrote: >> >> Hi. Apologies for breaking conventions of this list and >> top-posting.. >> >> It seems that the issue below is more of a question for the >> Ubuntu list, than Tomcat's. >> >> The standard /etc/init.d/tomcat9 startup script included in the >> Ubuntu tomcat9 package, should allow starting tomcat 9 on port 80 >> without any changes to the tomcat configuration or scripts (other >> than setting the Connector to port 80 in server.xml). If "it >> doesn't work", you should consult the Ubuntu user's support list, >> where you are more likely to find appropriate answers. See here >> : >> https://urldefense.proofpoint.com/v2/url?u=https-3A__ubuntu.com_suppo rt_community-2Dsupport&d=DwIDaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZ hHbOU&r=yU49ICjDxaD7z2G3Zm_yr4Iprw-m6yW-pk9yfkB8GpE&m=C-ylp1u0rXLaw8PuIu 2iihe8t9J5yoRDho4_9flKXd4&s=5Vjv2foGMSmFIvWhdp77aYdkojYCLQdZ7iYmgP1z16M& e= >> >> >> >> At another level : below, you mention trying authbind (which is >> what the standard Ubuntu startup script does), but "I could not >> get it to work". Did you check that the settings of authbind are >> correct, for port 80 ? See : >> https://urldefense.proofpoint.com/v2/url?u=http-3A__manpages.ubuntu.c om_manpages_bionic_man1_authbind.1.html&d=DwIDaQ&c=kbmfwr1Yojg42sGEpaQh5 ofMHBeTl9EI2eaqQZhHbOU&r=yU49ICjDxaD7z2G3Zm_yr4Iprw-m6yW-pk9yfkB8GpE&m=C - -ylp1u0rXLaw8PuIu2iihe8t9J5yoRDho4_9flKXd4&s=GXIhb1mYfUXA5OiXdNRVVG3HqNX u29cuaJW44oIbEvY&e= >> >> >> >> On 09.07.2019 15:49, Arbelo, Ralph wrote: >>> Hello, &
Re: Tomcat 9 & Port 80
Thank you for your reply, André. Unfortunately, the Tomcat 9 Ubuntu package is only available on Ubuntu 18 and 19 (at least that I could find). I'm on 16 at the moment (though I did think about upgrading) which is why I'm using the binary distribution from tomcat.apache.org. The good news is I was able to get authbind to work. If anyone is interested in the steps I used, please let me know. Thanks again, Ralph On 7/10/19, 5:29 AM, "André Warnier (tomcat)" wrote: Hi. Apologies for breaking conventions of this list and top-posting.. It seems that the issue below is more of a question for the Ubuntu list, than Tomcat's. The standard /etc/init.d/tomcat9 startup script included in the Ubuntu tomcat9 package, should allow starting tomcat 9 on port 80 without any changes to the tomcat configuration or scripts (other than setting the Connector to port 80 in server.xml). If "it doesn't work", you should consult the Ubuntu user's support list, where you are more likely to find appropriate answers. See here : https://urldefense.proofpoint.com/v2/url?u=https-3A__ubuntu.com_support_community-2Dsupport&d=DwIDaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=yU49ICjDxaD7z2G3Zm_yr4Iprw-m6yW-pk9yfkB8GpE&m=C-ylp1u0rXLaw8PuIu2iihe8t9J5yoRDho4_9flKXd4&s=5Vjv2foGMSmFIvWhdp77aYdkojYCLQdZ7iYmgP1z16M&e= At another level : below, you mention trying authbind (which is what the standard Ubuntu startup script does), but "I could not get it to work". Did you check that the settings of authbind are correct, for port 80 ? See : https://urldefense.proofpoint.com/v2/url?u=http-3A__manpages.ubuntu.com_manpages_bionic_man1_authbind.1.html&d=DwIDaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=yU49ICjDxaD7z2G3Zm_yr4Iprw-m6yW-pk9yfkB8GpE&m=C-ylp1u0rXLaw8PuIu2iihe8t9J5yoRDho4_9flKXd4&s=GXIhb1mYfUXA5OiXdNRVVG3HqNXu29cuaJW44oIbEvY&e= On 09.07.2019 15:49, Arbelo, Ralph wrote: > Hello, > > I have Tomcat 9.0.21 installed (binary distribution) on an Ubuntu 16.04 server. My Java version is OpenJDK 11.0.4. I have the JSVC built and run the dameon.sh script to start and stop Tomcat via a systemd script. Everything works great, but now I need to run it on port 80 & 443. On our old server we have a script we use, but it doesn’t work upon startup (due to the needing to use sudo to get privileges to bind to port 80). For this new build, I was hoping to streamline the process and have Tomcat start upon boot. I’ve been doing a lot of Google searching on binding port 80 on Tomcat, but most of what I found was for older versions. Here’s what I found: > >* Use iptables to redirect 8080 to 80 >* Proxy with NGINX or Apache >* Use authbind > > I’d rather not use iptables to redirect as (from what I understand) you still have to allow direct access to port 8080. > > I tried using authbind, but I could not get it to work. All the procedures I found were for older versions of Tomcat, so I don’t know if authbind will even work with Tomcat 9. > > Finally my questions- > >1. Has anyone successfully used authbind with Tomcat 9? >2. Anything I’m missing with getting Tomcat to bind with port 80? Should I just bite the bullet and use an HTTP proxy? > > Thank you! > Ralph > > Ralph Arbelo > Library IT Services - River Campus Libraries > University of Rochester > 121B Rush Rhees Library, Rochester, NY 14627 > o: 585.275.3449 - f: 585.275.1032 > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 9 & Port 80
Hello, I have Tomcat 9.0.21 installed (binary distribution) on an Ubuntu 16.04 server. My Java version is OpenJDK 11.0.4. I have the JSVC built and run the dameon.sh script to start and stop Tomcat via a systemd script. Everything works great, but now I need to run it on port 80 & 443. On our old server we have a script we use, but it doesn’t work upon startup (due to the needing to use sudo to get privileges to bind to port 80). For this new build, I was hoping to streamline the process and have Tomcat start upon boot. I’ve been doing a lot of Google searching on binding port 80 on Tomcat, but most of what I found was for older versions. Here’s what I found: * Use iptables to redirect 8080 to 80 * Proxy with NGINX or Apache * Use authbind I’d rather not use iptables to redirect as (from what I understand) you still have to allow direct access to port 8080. I tried using authbind, but I could not get it to work. All the procedures I found were for older versions of Tomcat, so I don’t know if authbind will even work with Tomcat 9. Finally my questions- 1. Has anyone successfully used authbind with Tomcat 9? 2. Anything I’m missing with getting Tomcat to bind with port 80? Should I just bite the bullet and use an HTTP proxy? Thank you! Ralph Ralph Arbelo Library IT Services - River Campus Libraries University of Rochester 121B Rush Rhees Library, Rochester, NY 14627 o: 585.275.3449 - f: 585.275.1032
Re: Websocket classes in tomcat-embed-core-7.0.52.jar
Thanks a lot. Was not aware that this is now in a separate package. Ralph On Thu, Feb 20, 2014 at 9:20 AM, Jacopo Cappellato < jacopo.cappell...@gmail.com> wrote: > On Feb 20, 2014, at 9:10 AM, Ralph Schaer wrote: > > > Hi > > > > The embedded core jar 7.0.52 no longer contains the websocket classes. > > It only contains an empty org.apache.tomcat.websocket package > > > > Version 7.0.50 of the embedded core contains all the websocket classes. > > > > Is this a intentional change or maybe a bug in the build process? > > This is true, however the embedded distribution now has a separate jar > with the websockets implementation: > > tomcat7-embed-websocket.jar > > Jacopo > > > > > > Ralph > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Websocket classes in tomcat-embed-core-7.0.52.jar
Hi The embedded core jar 7.0.52 no longer contains the websocket classes. It only contains an empty org.apache.tomcat.websocket package Version 7.0.50 of the embedded core contains all the websocket classes. Is this a intentional change or maybe a bug in the build process? Ralph
FileNotFoundException: JAR entry META-INF/spring.tld not found
Hi I'm fiddling with the latest Tomcat 8.0.0-RC3 and get the following WARNING log message. This happens on Windows and on Linux. I created a simple maven project: https://github.com/ralscha/tomcat8warning that demonstrates the problem. Clone it, create a war with mvn package and copy the war into the webapps directory. Open conf/server.xml and change unpackWARs to false. Then start Tomcat and the following warning message appears in the logs. This only happens with unpackWARs="false". When this option is true the warning does not appear. It also only happens with 8.0.0-RC3. The previous alpha version (8.0.0-RC1) does not show this warning. Anybody noticed a similar problem? 25-Sep-2013 18:01:52.617 WARNING [localhost-startStop-1] org.apache.tomcat.util.scan.StandardJarScanner.scan Failed to scan JAR [jar:file:/D:/java/apache-tomcat-8.0.0-RC3/webapps/springweb-0.0.1.war!/WEB-INF/lib/spring-webmvc-3.2.4.RELEASE.jar] from /WEB-INF/lib java.io.FileNotFoundException: JAR entry META-INF/spring.tld not found in D:\java\apache-tomcat-8.0.0-RC3\webapps\springweb-0.0.1.war at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:140) at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150) at java.net.URL.openStream(URL.java:1037) at org.apache.tomcat.util.descriptor.tld.TldResourcePath.openStream(TldResourcePath.java:109) at org.apache.tomcat.util.descriptor.tld.TldParser.parse(TldParser.java:43) at org.apache.jasper.servlet.TldScanner.parseTld(TldScanner.java:221) at org.apache.jasper.servlet.TldScanner.access$200(TldScanner.java:56) at org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan(TldScanner.java:259) at org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.java:300) at org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner.java:165) at org.apache.jasper.servlet.TldScanner.scanJars(TldScanner.java:208) at org.apache.jasper.servlet.TldScanner.scan(TldScanner.java:96) at org.apache.jasper.servlet.JasperInitializer.onStartup(JasperInitializer.java:57) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5265) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:702) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:698) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:968) at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1742) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724)
Re: Tomcat web application stops automatically
Am 15.04.2013 14:22, schrieb Rishad Ali: > I think I mentioned this in the question that I am using > ScheduledExecutorService to start threads every minute. This is not the > application running every minute, these are the threads I create. > And as I said It works fine for some time then it stops. > > Yes I checked the log but there is no sign of stopping application or > nothing about Too many database connections. Please don't top-post. When your application(s) stopped: take a thread dump and post it here. Ralph - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat web application stops automatically
Am 15.04.2013 11:31, schrieb Rishad Ali: > I have a dedicated server running CentOS 5.9, Apache-Tomcat 5.5.36. I > have written a JAVA web applications which runs every minute to collect > the data from multiple sensors. I am using ScheduledExecutorService to > execute the threads. (one thread for each sensor every minute and there > can be more than hundred sensors) The flow of the thread is > A web application can be deployed to tomcat and when it is deployed it can be running or not. It can't run every minute. > thread. The applications work fine but after some time(24 Hour - 48 > Hours) the applications stop working. I can't find out what the problem What does that mean? Did you take a look at the tomcat logfiles? Ralph - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
ecj 4.2.2
Just a quick note. I saw on the changelog that Tomcat 7.0.40 is using ecj 4.2.2. So I created a bundle for this ecj version (like I did for 4.2.1<http://marc.info/?l=tomcat-user&m=135966507114107&w=2>), uploaded it to Sonatype and only a few hours later it got approved. Ecj 4.2.2 is now already in the maven central repository and ready for use. https://issues.sonatype.org/browse/OSSRH-5787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel Ralph
Re: Tomcat 7.0.34 and ecj 3.7.2/4.2.1
The bundle got accepted. ecj 4.2.1 is now available from the maven central repository. Ralph On Sat, Jan 26, 2013 at 7:42 AM, Ralph Schaer wrote: > I started the process of uploading the ecj 4.2.1 artefacts to the maven > central repository. > I followed the description from Ian. > http://ianbrandt.com/2011/10/10/ecj-3-7-1-published-to-maven-central/ > > According to this documentation > > https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository > the process is in the last stage "My Bundle is Uploaded. What Next?". > So I have to wait for the sonatype people and see if they approve the > bundle. > > The files are in this staging repository: > https://oss.sonatype.org/content/repositories/central_bundles-274/ > > Ralph > > > On Mon, Jan 21, 2013 at 11:33 AM, Ralph Schaer wrote: > >> You find the ecj jar on this site: >> http://download.eclipse.org/eclipse/downloads/drops4/R-4.2.1-201209141800/ >> >> Section: >> JDT Core Batch Compiler >> >> >> Ralph >> >> On Mon, Jan 21, 2013 at 11:23 AM, Supun Malinga wrote: >> >>> Hi Guys, >>> >>> Where can I find the ecj 4.2.1 jar?, except from the tomcat >>> distribution. >>> >>> thank you. >>> >>> >>> On Fri, Jan 11, 2013 at 1:47 PM, Konstantin Kolinko >>> wrote: >>> >>> > 2013/1/11 Ralph Schaer : >>> > > Hi >>> > > >>> > > Tomcat 7.0.34 bumped ecj to version 4.2.1. But the pom file >>> > > of tomcat-embed-jasper still points to version 3.7.2 of ecj. >>> > > Is it safe to use ecj 3.7.2 with Tomcat 7.0.34? >>> > > It's unfortunately not possible to override this, because I haven't >>> found >>> > > the 4.2.1 artifact in the central repository. >>> > > >>> > >>> > 1. Thank you for reporting the issue. I fixed this in svn, but 7.0.35 >>> > has already been tagged several hours ago. >>> > >>> > 2. Absence of ecj 4.2.1 in central repository is not a stopper. It >>> > happened before and is expected to happen in the future. You can >>> > install it locally. >>> > >>> > http://markmail.org/message/xyw3bv2flmbhsdt4 >>> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=283745 >>> > >>> > 3. I personally would recommend to go with 4.2.1. >>> > >>> > It is known that Eclipse 3.7.2 fails to compile the current Tomcat >>> > trunk sources (the compiler crashes), 4.2.1 works fine. >>> > >>> > There was report by Jess Holle on a crash with 4.2.1, but what causes >>> > the crash is unknown and I have not observed anything like that. >>> > http://tomcat.markmail.org/thread/oe5wwu3dm2zcjp4m >>> > >>> > Anyway, if you are in doubt, you may try to run precompilation for >>> > your JSPs with JspC just to make sure that everything compiles nicely. >>> > (I do not suggest to actually use the compiled classes. I mean just to >>> > run a compilation to check that they are compilable). >>> > >>> > 4. The bump of ecj version included a change in one of java classes. >>> > >>> > @Override is a compile-time annotation. You should still be able to >>> > run with 3.7.2. >>> > http://svn.apache.org/viewvc?view=revision&revision=1411587 >>> > >>> > Best regards, >>> > Konstantin Kolinko >>> > >>> > - >>> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> > For additional commands, e-mail: users-h...@tomcat.apache.org >>> > >>> > >>> >>> >>> -- >>> Supun Malinga >>> >> >> >
Re: Tomcat 7.0.34 and ecj 3.7.2/4.2.1
I started the process of uploading the ecj 4.2.1 artefacts to the maven central repository. I followed the description from Ian. http://ianbrandt.com/2011/10/10/ecj-3-7-1-published-to-maven-central/ According to this documentation https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository the process is in the last stage "My Bundle is Uploaded. What Next?". So I have to wait for the sonatype people and see if they approve the bundle. The files are in this staging repository: https://oss.sonatype.org/content/repositories/central_bundles-274/ Ralph On Mon, Jan 21, 2013 at 11:33 AM, Ralph Schaer wrote: > You find the ecj jar on this site: > http://download.eclipse.org/eclipse/downloads/drops4/R-4.2.1-201209141800/ > > Section: > JDT Core Batch Compiler > > > Ralph > > On Mon, Jan 21, 2013 at 11:23 AM, Supun Malinga wrote: > >> Hi Guys, >> >> Where can I find the ecj 4.2.1 jar?, except from the tomcat distribution. >> >> thank you. >> >> >> On Fri, Jan 11, 2013 at 1:47 PM, Konstantin Kolinko >> wrote: >> >> > 2013/1/11 Ralph Schaer : >> > > Hi >> > > >> > > Tomcat 7.0.34 bumped ecj to version 4.2.1. But the pom file >> > > of tomcat-embed-jasper still points to version 3.7.2 of ecj. >> > > Is it safe to use ecj 3.7.2 with Tomcat 7.0.34? >> > > It's unfortunately not possible to override this, because I haven't >> found >> > > the 4.2.1 artifact in the central repository. >> > > >> > >> > 1. Thank you for reporting the issue. I fixed this in svn, but 7.0.35 >> > has already been tagged several hours ago. >> > >> > 2. Absence of ecj 4.2.1 in central repository is not a stopper. It >> > happened before and is expected to happen in the future. You can >> > install it locally. >> > >> > http://markmail.org/message/xyw3bv2flmbhsdt4 >> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=283745 >> > >> > 3. I personally would recommend to go with 4.2.1. >> > >> > It is known that Eclipse 3.7.2 fails to compile the current Tomcat >> > trunk sources (the compiler crashes), 4.2.1 works fine. >> > >> > There was report by Jess Holle on a crash with 4.2.1, but what causes >> > the crash is unknown and I have not observed anything like that. >> > http://tomcat.markmail.org/thread/oe5wwu3dm2zcjp4m >> > >> > Anyway, if you are in doubt, you may try to run precompilation for >> > your JSPs with JspC just to make sure that everything compiles nicely. >> > (I do not suggest to actually use the compiled classes. I mean just to >> > run a compilation to check that they are compilable). >> > >> > 4. The bump of ecj version included a change in one of java classes. >> > >> > @Override is a compile-time annotation. You should still be able to >> > run with 3.7.2. >> > http://svn.apache.org/viewvc?view=revision&revision=1411587 >> > >> > Best regards, >> > Konstantin Kolinko >> > >> > - >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> > For additional commands, e-mail: users-h...@tomcat.apache.org >> > >> > >> >> >> -- >> Supun Malinga >> > >
Re: Tomcat 7.0.34 and ecj 3.7.2/4.2.1
You find the ecj jar on this site: http://download.eclipse.org/eclipse/downloads/drops4/R-4.2.1-201209141800/ Section: JDT Core Batch Compiler Ralph On Mon, Jan 21, 2013 at 11:23 AM, Supun Malinga wrote: > Hi Guys, > > Where can I find the ecj 4.2.1 jar?, except from the tomcat distribution. > > thank you. > > > On Fri, Jan 11, 2013 at 1:47 PM, Konstantin Kolinko > wrote: > > > 2013/1/11 Ralph Schaer : > > > Hi > > > > > > Tomcat 7.0.34 bumped ecj to version 4.2.1. But the pom file > > > of tomcat-embed-jasper still points to version 3.7.2 of ecj. > > > Is it safe to use ecj 3.7.2 with Tomcat 7.0.34? > > > It's unfortunately not possible to override this, because I haven't > found > > > the 4.2.1 artifact in the central repository. > > > > > > > 1. Thank you for reporting the issue. I fixed this in svn, but 7.0.35 > > has already been tagged several hours ago. > > > > 2. Absence of ecj 4.2.1 in central repository is not a stopper. It > > happened before and is expected to happen in the future. You can > > install it locally. > > > > http://markmail.org/message/xyw3bv2flmbhsdt4 > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=283745 > > > > 3. I personally would recommend to go with 4.2.1. > > > > It is known that Eclipse 3.7.2 fails to compile the current Tomcat > > trunk sources (the compiler crashes), 4.2.1 works fine. > > > > There was report by Jess Holle on a crash with 4.2.1, but what causes > > the crash is unknown and I have not observed anything like that. > > http://tomcat.markmail.org/thread/oe5wwu3dm2zcjp4m > > > > Anyway, if you are in doubt, you may try to run precompilation for > > your JSPs with JspC just to make sure that everything compiles nicely. > > (I do not suggest to actually use the compiled classes. I mean just to > > run a compilation to check that they are compilable). > > > > 4. The bump of ecj version included a change in one of java classes. > > > > @Override is a compile-time annotation. You should still be able to > > run with 3.7.2. > > http://svn.apache.org/viewvc?view=revision&revision=1411587 > > > > Best regards, > > Konstantin Kolinko > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > -- > Supun Malinga >
Re: Problem with tomcat and JRE1.7
It seems that the war file that I was installing contains its own version of the servlet API, which evidently conflicts with the one Tomcat 7 is using. I'm not sure of the details yet, but it you're curious you can find the war file within this zip: http://semwebcentral.org/frs/download.php/513/Parliament-v2.7.4-darwin.zip Thanks, Ralph On 11/19/12 12:32 PM, André Warnier wrote: Hi. Thanks for the update. Ralph Grove wrote: The problem turned out to be one of the war files that I'm loading into Tomcat. JSP's work fine until that particular war file is deployed, but afterwards JSP's will no longer compile correctly. So what does that mean ? compiling the JSP's in that .war somehow corrupts the compiler ? Sounds interesting. Only those JSP's that were previously compiled continue to work correctly. Without that war file loaded, Tomcat is working normally with JRE 1.7, so the JRE version wasn't the problem. Thanks, Ralph On 11/17/12 9:39 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralph, On 11/16/12 3:15 PM, Ralph Grove wrote: I stopped tomcat, deleted work and all of the application directories that were derived from war files. Same problem after restarting, though. It looks like all JSP's are failing. Do you precompile any of your JSPs? I would expect something like this to happen if you upgraded Tomcat itself, but the JRE shouldn't matter. What happens if you downgrade the JRE? - -chris ... .. -- Ralph F Grove, Ph.D. Professor James Madison University Department of Computer Science - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with tomcat and JRE1.7
The problem turned out to be one of the war files that I'm loading into Tomcat. JSP's work fine until that particular war file is deployed, but afterwards JSP's will no longer compile correctly. Only those JSP's that were previously compiled continue to work correctly. Without that war file loaded, Tomcat is working normally with JRE 1.7, so the JRE version wasn't the problem. Thanks, Ralph On 11/17/12 9:39 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralph, On 11/16/12 3:15 PM, Ralph Grove wrote: I stopped tomcat, deleted work and all of the application directories that were derived from war files. Same problem after restarting, though. It looks like all JSP's are failing. Do you precompile any of your JSPs? I would expect something like this to happen if you upgraded Tomcat itself, but the JRE shouldn't matter. What happens if you downgrade the JRE? - -chris ... -- Ralph F Grove, Ph.D. Professor James Madison University Department of Computer Science - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with tomcat and JRE1.7
I stopped tomcat, deleted work and all of the application directories that were derived from war files. Same problem after restarting, though. It looks like all JSP's are failing. Ralph On 11/16/12 3:01 PM, Daniel Mikusa wrote: On Nov 16, 2012, at 2:06 PM, Ralph Grove wrote: I just upgraded my JRE from 1.6 to 1.7, and the tomcat home page now throws an exception (below). The example apps, and my own apps are still working OK, though. Anyone else noticed this problem? Have not seen this before. Just a guess, but maybe try stopping Tomcat, clearing out the work directory and restarting Tomcat. Dan System configuration: MacOS 10.8.2 JRE 1.7.0_09 Tomcat 7.0.32 The server is at http://geo-query.cs.jmu.edu Thanks, Ralph Grove *type* Exception report *message* _java.lang.AbstractMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext;_ *description* _The server encountered an internal error that prevented it from fulfilling this request._ *exception* javax.servlet.ServletException: java.lang.AbstractMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext; org.apache.jasper.servlet.JspServlet.service(JspServlet.java:343) javax.servlet.http.HttpServlet.service(HttpServlet.java:722) *root cause* java.lang.AbstractMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext; org.apache.jasper.compiler.Validator$ValidateVisitor.(Validator.java:514) org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1795) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:217) org.apache.jasper.compiler.Compiler.compile(Compiler.java:373) org.apache.jasper.compiler.Compiler.compile(Compiler.java:353) org.apache.jasper.compiler.Compiler.compile(Compiler.java:340) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:646) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) javax.servlet.http.HttpServlet.service(HttpServlet.java:722) *note* _The full stack trace of the root cause is available in the Apache Tomcat/7.0.32 logs. _ full trace: Nov 16, 2012 1:36:00 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet [jsp] in context with path [] threw exception [java.lang.AbstractMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext;] with root cause java.lang.AbstractMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext; at org.apache.jasper.compiler.Validator$ValidateVisitor.(Validator.java:514) at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1795) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:217) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:373) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:353) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:340) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:646) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java
Problem with tomcat and JRE1.7
I just upgraded my JRE from 1.6 to 1.7, and the tomcat home page now throws an exception (below). The example apps, and my own apps are still working OK, though. Anyone else noticed this problem? System configuration: MacOS 10.8.2 JRE 1.7.0_09 Tomcat 7.0.32 The server is at http://geo-query.cs.jmu.edu Thanks, Ralph Grove *type* Exception report *message* _java.lang.AbstractMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext;_ *description* _The server encountered an internal error that prevented it from fulfilling this request._ *exception* javax.servlet.ServletException: java.lang.AbstractMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext; org.apache.jasper.servlet.JspServlet.service(JspServlet.java:343) javax.servlet.http.HttpServlet.service(HttpServlet.java:722) *root cause* java.lang.AbstractMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext; org.apache.jasper.compiler.Validator$ValidateVisitor.(Validator.java:514) org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1795) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:217) org.apache.jasper.compiler.Compiler.compile(Compiler.java:373) org.apache.jasper.compiler.Compiler.compile(Compiler.java:353) org.apache.jasper.compiler.Compiler.compile(Compiler.java:340) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:646) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) javax.servlet.http.HttpServlet.service(HttpServlet.java:722) *note* _The full stack trace of the root cause is available in the Apache Tomcat/7.0.32 logs. _ full trace: Nov 16, 2012 1:36:00 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet [jsp] in context with path [] threw exception [java.lang.AbstractMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext;] with root cause java.lang.AbstractMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext; at org.apache.jasper.compiler.Validator$ValidateVisitor.(Validator.java:514) at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1795) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:217) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:373) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:353) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:340) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:646) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722)
Re: Catalina.out log level
Am 19.10.2012 21:32, schrieb vicky007aggar...@yahoo.co.in: > Thanks ralph for responding > Just only below line is enough?? Yes. You can find more info about logging with Tomcat here: http://tomcat.apache.org/tomcat-7.0-doc/logging.html Regards, Ralph - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Catalina.out log level
Am 19.10.2012 14:49, schrieb vicky007aggar...@yahoo.co.in: > Hi All, > > Can you please suggest how to change the log level of tomcat catalina.out > file. > > I did change in the logging.properties for all handlers to finest but still > catalina.out showing log levels with Info level only whereas all other log > files have finest log level set (e.g. Host-manager.log/manager.log) > > Kindly help > > Thanks, > Vicky > Hi Vicky, you need to add: org.apache.catalina.level=FINEST Regards, Ralph - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Authenticate requests from localhost using tomcat RemoteAddrFilter
Jaikit, Am 23.09.2012 00:04, schrieb Jaikit Savla: > Hello Users, > > I have some admin api's which I want to have restricted access - such that > only if the request originates from localhost - it will execute. > For that I am using tomcat's RemoteAddrfilter what exactly do you mean with admin api's? > > Remote Address Filter > > org.apache.catalina.filters.RemoteAddrFilter > > allow > 127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1 > > > > Remote Address Filter > /* > > see http://www.oracle.com/technetwork/java/filters-137243.html „A filter dynamically intercepts requests and responses to transform or use the information contained in the requests or responses.” So this Is something that is part of a web application which is running on tomcat. > Now when I execute the request from localhost - request fails with 403. > Reason being "REMOTE_ADDR" is set with actual ip of the machine and filter > does string comparison of ip. Hence it fails. > Any clue on how to resolve this use case ? > > > > > -bash-4.1$ curl -v http://localhost/ws/local/info > * About to connect() to localhost port 80 (#0) > * Trying 127.0.0.1... connected > * Connected to localhost (127.0.0.1) port 80 (#0) >> GET /ws/local/vip/info HTTP/1.1 >> User-Agent: curl/7.21.7 (x86_64-unknown-linux-gnu) libcurl/7.21.7 >> OpenSSL/0.9.8o zlib/1.2.3 libidn/1.18 libssh2/1.2.2 >> Host: localhost >> Accept: */* >> > < HTTP/1.1 403 Forbidden I am guessing here: if you want to restrict access to your tomcat server to certain clients, you could solve this by configuring your firewall accordingly. Ralph - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Problems loading external jar in my app !
Am 13.09.2012 07:42, schrieb joel badia escolà: > Hello everyone, i have a problem with my jsp app for adding external > jars. First of all I have tried the same code and app directory > structure in netbeans ide "built-in" tomcat and works fine, but when i > try to serve my app in my tomcat installation (installed using > aptitude) it seems that it's impossible to locate the external jar. > On which OS did you install tomcat6? > I tried to put weka.jar in all this directories my-app/WEB-INF/lib/ & > /var/lib/tomcat6/common/ & /var/lib/tomcat6/server/ & > /usr/share/tomcat6/lib/ > If your OS would be Debian or Ubuntu, /usr/share/tomcat6/lib/ is the place to make weka.jar available for all webapps on tomcat. After dropping it in there, did you restart tomcat? Have you checked the file permissions of weka.jar? It has to be readable for the user tomcat6 is running with. Regards, Ralph - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: JNI error under tomcat: java.lang.UnsatisfiedLinkError
do you get this error upon first deployment or re-deploy?
do you restart tomcat after you redeploy your jni app?
From: users-return-214329-racarlson=mediacomcc@tomcat.apache.org
[users-return-214329-racarlson=mediacomcc@tomcat.apache.org] On Behalf Of
Shay Rojansky [r...@roji.org]
Sent: Saturday, July 03, 2010 12:40 AM
To: Tomcat Users List
Subject: Re: JNI error under tomcat: java.lang.UnsatisfiedLinkError
Hi Dennis.
So do you see the "Load library successful" message?
Also, if I remember correctly, the code in eval.java is not a safe way to
load a native library. It's a very good idea to place the System.loadLibrary
in a static { } block, instead of in a method. The way your class is
written, it's possible for the run method to be executed more than once, in
which case loadLibrary will be called more than once (and so will the native
initModels). Not sure what the effects are and if it's related to your
problem but it's a good idea to avoid trouble by fixing it.
Shay
On Fri, Jul 2, 2010 at 3:46 AM, dennis ch wrote:
> Hi,
>
> I have a java class (eval.java) that invokes a native method in an so file
> (libmodel.so, using SWIG 1.3.29 to generate JNI code/wrapper and compiled
> the library). I can use System.loadLibrary() to load the libmodel.so
> without
> any error (-Djava.library.path=/usr/lib), and the native method initModel()
> works fine as a standalone application.
>
> However, when I deploy it as a web service (tomcat 6.0.26 + axis2 1.5.1 +
> eclipse jee helios) to call the native method, I got the following error
> (the first line means the .so was successfully loaded):
>
> Load library successfully
>
> [ERROR] com.model.modelJNI.initModel()V
> java.lang.reflect.InvocationTargetException
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>at java.lang.reflect.Method.invoke(Method.java:597)
>at
> org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:194)
>at
> org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:102)
>at
> org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
>at
> org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114)
>at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173)
>at
> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
>at
> org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:142)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
>at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
>at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
>at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
>at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
>at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.UnsatisfiedLinkError: com.model.modelJNI.initModel()V
>at com.model.modelJNI.initModel(Native Method)
>at com.model.model.initModel(model.java:13)
>at com.webservice.run(EvalVita.java:763)
>... 25 more
>
>
> Below is the body of Eval.java:
>
> import com.model.*;
>
> public class Eval {
>
> static void loadModel() {
>
>try {
>System.loadLibrary("model");
>
>System.out.println("Load library successfully");
>
>} catch (UnsatisfiedLinkError e) {
>
>System.err.println("Native code library failed to load." + e);
>
>}
> }
> public void run() {
>
>loadModel();
>model.initModel();
> }
> }
>
>
> Do I miss anything here? Any input is appreciated!
>
> Dennis
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 5.5 creates 0 byte files
you can also try the oreilly file upload api, I have used it in many projects
without issue
http://www.servlets.com/cos/ (download)
http://java.itags.org/java-essentials/11012/ (an example)
From: users-return-214291-racarlson=mediacomcc@tomcat.apache.org
[users-return-214291-racarlson=mediacomcc@tomcat.apache.org] On Behalf Of
Murat Birben [muratbir...@gmail.com]
Sent: Friday, July 02, 2010 6:01 AM
To: Tomcat Users List; p...@pidster.com
Subject: Re: Tomcat 5.5 creates 0 byte files
Yes 0 byte files are causing the disk to run out of space
@Andre Warnier
I'm not actually saving files on the server. I just tried to simplify my
problem and tried that simple code. Now i'll give a try to apache fileupload
api, thanks for advice
On Fri, Jul 2, 2010 at 11:52 AM, Pid wrote:
> On 02/07/2010 09:43, Murat Birben wrote:
> > Hi all,
> >
> > I have a very simple file upload mechanism in java. I just take the file
> and
> > save it on the server. I'm testing this simple code with selenium and
> *when
> > a timeout occurs in the selenium test *tomcat creates 0 byte files under
> > tomcat_home/work/Catalina/localhost/uploadServlet/ directory as
> MultiPart*
> > files. It creates thousands of files, until there is no disk space left
> on
> > device. What may cause this problem? How can I solve this? Is there
> anyone
> > has an idea about this?
>
> Thousands of 0 byte files are causing the disk to run out of space?
>
>
> p
>
> > My environment is: Ubuntu - 8.04 server, apache tomcat - 5.5.29, sun java
> > 1.6
> >
> > Thanks,
> >
> > Here is the code snippet that i use
> >
> > File fFile = null;
> > FileOutputStream fileOutputStream = null;
> > FileInputStream fileInputStream = null;
> > try {
> >
> > String strFileName = request.getParameter("FileName");
> > String strPath = request.getParameter("Path");
> > //String strMediaType = request.getParameter("MediaType");
> >
> > //String strDescription =
> request.getParameter("Description");
> > fFile = (File) request.getAttribute("Content");
> >
> > int index = strPath.length() - 1; //If the user forgets to
> > put the last / for the path... We put it for him/her
> >
> > if (strPath.charAt(index) != '/') {
> > strPath += "/";
> > }
> > if (!new File(strPath).exists()) {
> > new File(strPath).mkdirs();
> > }
> >
> > File file = new File(strPath + strFileName);
> > fileOutputStream = new FileOutputStream(file);
> > fileInputStream = new FileInputStream(fFile);
> >
> > byte[] bBuf = new byte[1024];
> >
> > int iBufLen = 0;
> > int iReadLen = 1024;
> > int iTotelLen = 0;
> > /*read 1024 bytes at a time*/
> > while ((iBufLen = fileInputStream.read(bBuf)) != -1) {
> >
> > fileOutputStream.write(bBuf);
> > fileOutputStream.flush();
> > iTotelLen += iBufLen;
> > if (fileInputStream.available() < iReadLen) {
> > iReadLen = fileInputStream.available();
> >
> > break;
> > }
> > }
> >
> > byte[] tempbBuf = new byte[iReadLen];
> > fileInputStream.read(tempbBuf, 0, iReadLen);
> >
> > fileOutputStream.write(tempbBuf);
> >
> >
> > } catch (IOException ex) {
> > ex.printStackTrace();
> > } finally {
> > fileOutputStream.close();
> > fileInputStream.close();
> >
> > if (fFile.exists()) {
> >
> > fFile.delete();
> > }
> > }
> >
> >
> >
>
>
>
--
Murat BIRBEN
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: need help setting up tomcat with ssl client authentication
I changed server.xml to: and now it works with all clients, firefox, openssl s_client, and php client thanks for you all your help, its much appreciated :) From: users-return-214184-racarlson=mediacomcc@tomcat.apache.org [users-return-214184-racarlson=mediacomcc@tomcat.apache.org] On Behalf Of Christopher Schultz [ch...@christopherschultz.net] Sent: Wednesday, June 30, 2010 9:40 PM To: Tomcat Users List Subject: Re: need help setting up tomcat with ssl client authentication -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralph, On 6/30/2010 5:07 PM, Ralph Carlson wrote: > (d) have client Authorization on - with it off tomcat ssl works just fine, > when its turned on I get this error > so far I have been following the steps listed in this tomcat user group > message > http://marc.info/?l=tomcat-user&m=106293430225790&w=2 Try something a bit more recent than 2003. I was able to get client certs working with my own CA, and I was manually checking the client cert instead of having Tomcat do it. However, if your code can do it, so can Tomcat. Try reading-through this thread: http://markmail.org/message/kzxsamuiu6bldjmv > maxThreads="150" scheme="https" secure="true" >clientAuth="true" >keystoreFile="/server.ks" >keystorePass="[...]" >sslProtocol="TLS" /> I think you also need a truststoreFile and friends. Try re-reading the documentation at http://tomcat.apache.org/tomcat-6.0-doc/config/http.html specifically looking for "client cert". - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwr8f0ACgkQ9CaO5/Lv0PDFxQCcDrMdAJbl0adm44Dgnyd6fWqV aPEAnjPNCOXwmU847G/7IvZuBU9hnK2A =mNS+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: using Servlet Filter to rewrite domain of JSESSIONID cookie?
can you extend org.apache.catalina.connector.Response adding the HttpResponse
object and its getter/setter
and call that before valve.invoke()
also depending on what you are putting in your cookie and if the users are
logging on or not (you could also use ipaddress but that is flaky is they are
using proxies) I usually just put the custom user settings in a database now as
most virus scanner and malware scanner keep removing my users cookies anyway
From: users-return-214168-racarlson=mediacomcc@tomcat.apache.org
[users-return-214168-racarlson=mediacomcc@tomcat.apache.org] On Behalf Of
Nikita Tovstoles [nikita.tovsto...@gmail.com]
Sent: Wednesday, June 30, 2010 6:20 PM
To: Tomcat Users List
Subject: using Servlet Filter to rewrite domain of JSESSIONID cookie?
I'd like to make session cookie domain-wide, and ignore subdomains - in
Tomcat 6. So for app reachable via my.site.com and www.site.com, I'd like to
have session cookie's domain be ".site.com". I thought of doing so using a
ServletResponseWrapper and a servlet Filter:
@Override
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException,
ServletException
{
if (!(response instanceof
SessionCookieDomainSettingServletResponseWrapper))
{
response = new
SessionCookieDomainSettingServletResponseWrapper((HttpServletResponse)
response);
}
chain.doFilter(request, response);
}
and in wrapper:
@Override
public void addCookie(Cookie cookie)
{
if (cookie != null && SESSION_COOKIE_NAME.equals(cookie.getName()))
{
// update domain name to just the domain
stripSubDomain(cookie);
}
super.addCookie(cookie);
}
However, JSESSIONID continues to be set to FQ host name ("my.site.com").
Is it because Tomcat internals do not use HttpServletResponse.addCookie() to
set JSESSIONID or is that cookie set before filter chain gets executed?
If so, sounds like Filter is (sadly) not applicable for this case, and I
have to create a custom Valve? Any tips on how to
wrap org.apache.catalina.connector.Response - valve.invoke() does not take
HttpServletResponse...
thanks
-nikita
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: need help setting up tomcat with ssl client authentication
I am starting and stopping tomcat using startup.bat and shutdown.bat from the command line I am not using the apr I copied /server.ks into c:\tomcat folder in an attempt to get it working if I change it to a fake name it throws an error so I think its reading it the console looks like: Jun 30, 2010 7:46:25 PM org.apache.catalina.core.AprLifecycleListener init INFO: The APR based Apache Tomcat Native library which allows optimal performanc e in production environments was not found on the java.library.path: C:\Program Files\Java\jdk1.5.0_17\bin;.;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32; C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\ATI Technologies\ATI.ACE\Co re-Static;C:\Program Files\Common Files\GTK\2.0\bin;C:\Program Files\Java\jdk1.5 .0_17\bin;C:\openssl\bin; Jun 30, 2010 7:46:25 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-8080 Jun 30, 2010 7:46:27 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-443 Jun 30, 2010 7:46:27 PM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 2248 ms Jun 30, 2010 7:46:27 PM org.apache.catalina.core.StandardService start INFO: Starting service Catalina Jun 30, 2010 7:46:27 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.20 Jun 30, 2010 7:46:28 PM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8080 Jun 30, 2010 7:46:28 PM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-443 Jun 30, 2010 7:46:28 PM org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:8009 Jun 30, 2010 7:46:28 PM org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/15 config=null Jun 30, 2010 7:46:28 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 1274 ms From: users-return-214173-racarlson=mediacomcc@tomcat.apache.org [users-return-214173-racarlson=mediacomcc@tomcat.apache.org] On Behalf Of Pid [...@pidster.com] Sent: Wednesday, June 30, 2010 7:19 PM To: Tomcat Users List Subject: Re: need help setting up tomcat with ssl client authentication On 30/06/2010 23:45, Ralph Carlson wrote: > the tomcats logs have no errors in them, they end after start up (I haven't > installed any apps yet, just trying to get to the tomcat manager with ssl) Are you using APR? This path: >keystoreFile="/server.ks" doesn't appear to match this path: > C:\ssl\server\server.ks Are there any errors in the logs, or displayed on the console, when Tomcat starts up? (How are you starting the server, as a service, or using startup.bat?) p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: need help setting up tomcat with ssl client authentication
the tomcats logs have no errors in them, they end after start up (I haven't installed any apps yet, just trying to get to the tomcat manager with ssl) I configured the tomcat keystore as follows (openssl commands included): [1] create folders c:\ssl\ca, c:\ssl\server and c:\ssl\client and ca.srl with 02 [2] openssl req -new -newkey rsa:1024 -nodes -out c:\ssl\ca\ca.csr -keyout c:\ssl\ca\ca.key -config "C:\ssl\openssl.cnf" country=US state=newyork city=fishkill organization_name=myca organization_unit=myca common_name=myca email=racarl...@medaicomcc.com [3] openssl x509 -trustout -signkey c:\ssl\ca\ca.key -days 365 -req -in c:\ssl\ca\ca.csr -out c:\ssl\ca\ca.pem [4] keytool -import -keystore "%JAVA_HOME%/jre/lib/security/cacerts" -file C:\ssl\ca\ca.pem -alias my_ca **[5] keytool -genkey -alias tomcat -keyalg RSA -keysize 1024 -keystore C:\ssl\server\server.ks -storetype JKS What is your first and last name? myserver.localhost.com What is the name of your organizational unit? mycompany What is the name of your organization? mycompany What is the name of your City or Locality? fishkill What is the name of your State or Province? newyork What is the two-letter country code for this unit? US **[6] keytool -certreq -keyalg RSA -alias tomcat -file C:\ssl\server\server.csr -keystore C:\ssl\server\server.ks [7] amend the text which reads "NEW CERTIFICATE REQUEST" to "CERTIFICATE REQUEST" [8] openssl x509 -CA C:\ssl\ca\ca.pem -CAkey C:\ssl\ca\ca.key -CAserial C:\ssl\ca\ca.srl -req -in C:\ssl\server\server.csr -out C:\ssl\server\server.crt -days 365 **[9] keytool -import -alias tomcat -keystore C:\ssl\server\server.ks -trustcacerts -file C:\ssl\server\server.crt **[10] keytool -import -alias my_ca -keystore C:\ssl\server\server.ks -trustcacerts -file C:\ssl\ca\ca.pem [11] openssl req -new -newkey rsa:512 -nodes -out C:\ssl\client\client1.req -keyout C:\ssl\client\client1.key Country Name ? US State or Province Name ? newyork Locality Name (eg, city) ? fishkill Organization Name ? mycompany Organizational Unit Name ? mycompany Common Name (eg, YOUR name) ? localhost <-- this value is in tomcat-users.xml Email Address ? racarl...@mediacomcc.com [12] openssl x509 -CA C:\ssl\ca\ca.pem -CAkey C:\ssl\ca\ca.key -CAserial C:\ssl\ca\ca.srl -req -in C:\ssl\client\client1.req -out C:\ssl\client\client1.pem -days 365 [13] openssl pkcs12 -export -clcerts -in C:\ssl\client\client1.pem -inkey C:\ssl\client\client1.key -out C:\ssl\client\client1.p12 -name "my_client_certificate" I also tried importing the client.pem and apache.pem from below into the keystore (not change in error) openssl pkcs12 -in c:\ssl\client\client1.p12 -out c:\ssl\client\apache.pem -nodes -passin pass:MC126801$ From: users-return-214164-racarlson=mediacomcc@tomcat.apache.org [users-return-214164-racarlson=mediacomcc@tomcat.apache.org] On Behalf Of Pid [...@pidster.com] Sent: Wednesday, June 30, 2010 5:25 PM To: Tomcat Users List Subject: Re: need help setting up tomcat with ssl client authentication On 30/06/2010 22:07, Ralph Carlson wrote: > tomcat version 6.0.20 > os: windows xp sp3 professional edition > sun java jdk 1.5.11 > > I am trying to do the following > (a) create a certificate authority and self sign server and client > certificates using openssl and keytool > (b) import the keytool keystore into tomcat > (c) verify the certificate chaing using openssl verify (which does work and > returns ok for all 3 certificates) > (d) have client Authorization on - with it off tomcat ssl works just fine, > when its turned on I get this error Which error? What is in the Tomcat logs when the problem occurs? > so far I have been following the steps listed in this tomcat user group > message > http://marc.info/?l=tomcat-user&m=106293430225790&w=2 How did you configure Tomcat to use the certificates in (b)? What is your Tomcat Connector config in server.xml? p > but get this message from openssl s_client -cert c:\ssl\client\client.pem > -CAfile c:\ssl\ca\ca.pem -connect localhost:443 > > 3772:error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate > unknown:.\ssl\s3_pkt.c:1061:SSL alert number 46 > 3772:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake > failure:.\ssl\s23_lib.c:188: > > and these messages from firefox (after importing the certificate) > initially 'sslv3 alert certificate unknown' , then just 'SSL peer was not > expecting a handshake message it received' after a few tries > > does anyone know how to do this or has anyone done this before, > thanks for you help in advance > >
need help setting up tomcat with ssl client authentication
tomcat version 6.0.20 os: windows xp sp3 professional edition sun java jdk 1.5.11 I am trying to do the following (a) create a certificate authority and self sign server and client certificates using openssl and keytool (b) import the keytool keystore into tomcat (c) verify the certificate chaing using openssl verify (which does work and returns ok for all 3 certificates) (d) have client Authorization on - with it off tomcat ssl works just fine, when its turned on I get this error so far I have been following the steps listed in this tomcat user group message http://marc.info/?l=tomcat-user&m=106293430225790&w=2 but get this message from openssl s_client -cert c:\ssl\client\client.pem -CAfile c:\ssl\ca\ca.pem -connect localhost:443 3772:error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown:.\ssl\s3_pkt.c:1061:SSL alert number 46 3772:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:.\ssl\s23_lib.c:188: and these messages from firefox (after importing the certificate) initially 'sslv3 alert certificate unknown' , then just 'SSL peer was not expecting a handshake message it received' after a few tries does anyone know how to do this or has anyone done this before, thanks for you help in advance - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: relation between Tomcat and Apache Commons
Petr, Are you executing JSVC as root or no? If you aren't, then I can understand why your non-root account cannot bind to 443. The way JSVC works is by starting up under the account that executed it and then spawning a child process that is owned by the account specified in the -user option. A- On 10/31/08 10:56 AM, "Petr Sumbera" <[EMAIL PROTECTED]> wrote: > > > Caldarale, Charles R wrote: >> >>> From: Andrew Ralph Feller, afelle1 [mailto:[EMAIL PROTECTED] >>> Subject: Re: relation between Tomcat and Apache Commons >>> >>> it seems possible to run Tomcat on a non-privileged port with a >>> non-root account and have requests for port 443 redirected to >>> Tomcat's listening port. >> >> Of course - but it requires additional configuration (e.g., iptables, >> firewall). Using jsvc may be simpler and avoid dependencies external to >> Tomcat. >> > > What I have just found is that jsvc enables Tomcat to bind privileged port > only on Linux (it's using capabilities). > > For example on Solaris one need to add net_privadd privilege for Tomcat > user. This can be done by modifying /etc/user_attr. In such case I believe > there is no need for jsvc. > > grep tomcat /etc/user_attr > tomcatdefaultpriv=basic,net_privaddr > > -- > > Petr -- Andrew R. Feller, Analyst Information Technology Services 200 Fred Frey Building Louisiana State University Baton Rouge, LA 70803 (225) 578-3737 (Office) (225) 578-6400 (Fax) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: relation between Tomcat and Apache Commons
That is a good point. What is your preferred method of running Tomcat? JSVC? Startup / shutdown scripts? Front-end with Apache HTTP server? Standalone? A- On 10/30/08 3:49 PM, "Caldarale, Charles R" <[EMAIL PROTECTED]> wrote: >> From: Andrew Ralph Feller, afelle1 [mailto:[EMAIL PROTECTED] >> Subject: Re: relation between Tomcat and Apache Commons >> >> it seems possible to run Tomcat on a non-privileged port with a >> non-root account and have requests for port 443 redirected to >> Tomcat's listening port. > > Of course - but it requires additional configuration (e.g., iptables, > firewall). Using jsvc may be simpler and avoid dependencies external to > Tomcat. > > - 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 start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Andrew R. Feller, Analyst Information Technology Services 200 Fred Frey Building Louisiana State University Baton Rouge, LA 70803 (225) 578-3737 (Office) (225) 578-6400 (Fax) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: relation between Tomcat and Apache Commons
Chuck, I'm already following up on this on a different thread, however it seems possible to run Tomcat on a non-privileged port with a non-root account and have requests for port 443 redirected to Tomcat's listening port. This way Tomcat can run as non-root and no need to compile and use JSVC. I haven't done this yet, which is why I started the "JSVC vs startup / shutdown scripts" thread. Would love your $0.02, A- On 10/30/08 1:56 PM, "Caldarale, Charles R" <[EMAIL PROTECTED]> wrote: >> From: Petr Sumbera [mailto:[EMAIL PROTECTED] >> Subject: Re: relation between Tomcat and Apache Commons >> >> Btw I don't see any benefit using jsvc. Is somebody using it? Why? > > Judging from the comments on this list, many people are using it. The primary > reason is to avoid running Tomcat as root (principle of least privilege) when > using ports 80 and 443. > > - 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 start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Andrew R. Feller, Analyst Information Technology Services 200 Fred Frey Building Louisiana State University Baton Rouge, LA 70803 (225) 578-3737 (Office) (225) 578-6400 (Fax) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSVC vs standard startup / shutdown scripts
Thanks for the reply David! If you startup jsvc and do "ps axu | grep jsvc", you will find two processes with one being owned by root and the other by the non-root account. The non-root process will actually handle the incoming requests, however the root process is needed to bind to port 443 since it is a privilege port. On 10/30/08 1:55 PM, "David Smith" <[EMAIL PROTECTED]> wrote: >> >> I don't have any personal issue with moving to running Tomcat directly as >> the non-privileged account meant for Tomcat ... > > Just to clarify, jsvc runs tomcat as an unprivileged user as well. One > advantage to jsvc is it allows tomcat to be run by itself without funky > iptables rules or a front-end server. It's a simpler setup and overall > I'm a firm believer in simpler = better. > > --David > > Andrew Ralph Feller, afelle1 wrote: >> Thanks for the response Torsten! >> >> In our environment, the machines we have Tomcat running on strictly use >> Tomcat 6, APR for SSL support, and we load balance applications through an >> external load balancer. We have been able to get by without brining HTTPD >> for things like mod_rewrite or any of the PAMs, so I would like to keep it >> as simple as possible. >> >> I don't have any personal issue with moving to running Tomcat directly as >> the non-privileged account meant for Tomcat, however I am curious about the >> trade offs especially related to security. >> >> Thanks! >> >> On 10/30/08 12:37 PM, "[EMAIL PROTECTED]" >> <[EMAIL PROTECTED]> wrote: >> >> >>> Hi Andrew, >>> >>> We let all our Tomcats run on a non-privileged port and use some init script >>> using startup.sh/shutdown.sh, and have an Apache httpd forwarding requests >>> with AJP. >>> >>> We then use Apache httpd for things like terminating SSL, do RADIUS or LDAP >>> authentication, load balancing several Tomcat instances and so on. >>> >>> I think it is a good and common setup like that. >>> >>> Torsten >>> >>> -Original Message- >>> From: Andrew Feller [mailto:[EMAIL PROTECTED] >>> Sent: 30. oktober 2008 18:16 >>> To: users@tomcat.apache.org >>> Cc: Brad Cupit >>> Subject: JSVC vs standard startup / shutdown scripts >>> >>> QUESTION: What is the best practice for running Tomcat? JSVC daemon or >>> startup / shutdown scripts as a non-root user and forwarding HTTPS requests >>> to a non-privileged port? >>> >>> While reading the Professional Apache Tomcat 6 (ISBN: 978-0-471-75361-2), >>> they recommend running Tomcat to start it up using the startup script >>> provided in the Tomcat binary and having your firewall forward requests from >>> HTTPS to a non-privileged port. This is very interesting for two reasons: >>> >>>1. The book never mentions JSVC, which the Tomcat documentation does >>>2. We believed using JSVC was the only way to run as a non-root user, >>>which doesn't seem to be the case now >>> >>> I would appreciate any feedback about the trade offs and why people choose >>> one over the other. >>> >>> Thanks, >>> Andrew >>> >>> - >>> To start a new topic, e-mail: users@tomcat.apache.org >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> > > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Andrew R. Feller, Analyst Information Technology Services 200 Fred Frey Building Louisiana State University Baton Rouge, LA 70803 (225) 578-3737 (Office) (225) 578-6400 (Fax) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem to install APR Tomcat Native Library
Torsten, What is your LD_LIBRARY_PATH set to? Is it something like this: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/apr/lib Are there world permissions for anyone to read this directory? I know you mentioned that you front-end Tomcat with HTTPD and assumed your use of APR is to free Tomcat from depending on HTTPD for HTTPS. A- On 10/30/08 12:41 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Hi Martin, > > It is Solaris SPARC. Would it help to copy shared libs into the JRE bin > folder? I symlinked them into $JAVA_HOME/jre/lib/sparc but that didn't help > either. > > Torsten > > -Original Message- > From: Martin Gainty [mailto:[EMAIL PROTECTED] > Sent: 30. oktober 2008 18:34 > To: Tomcat Users List > Subject: RE: Problem to install APR Tomcat Native Library > > > pls follow Andrew's advice..if windows its probably a dll? so you'll want to > copy apr-1.lib to %JRE_HOME%\bin > > Martin > __ > Disclaimer and confidentiality note > Everything in this e-mail and any attachments relates to the official business > of Sender. This transmission is of a confidential nature and Sender does not > endorse distribution to any party other than intended recipient. Sender does > not necessarily endorse content contained within this transmission. > > >> Date: Thu, 30 Oct 2008 12:17:51 -0500 >> Subject: Re: Problem to install APR Tomcat Native Library >> From: [EMAIL PROTECTED] >> To: users@tomcat.apache.org >> >> Torsten, >> >> Have you updated your LD_LIBRARY_PATH to include APR lib? >> >> A- >> >> >> On 10/30/08 12:15 PM, "[EMAIL PROTECTED]" >> <[EMAIL PROTECTED]> wrote: >> >>> I am trying to install the APR Tomcat Native Library on a Solaris SPARC >>> server. >>> >>> Since it has only OpenSSL installed and no build system available, I >>> compiled >>> libapr 1.3.3 and libtcnative 1.1.14 on another machine with the same OS. >>> >>> I then copied the lib folders of both libs to the server, and added the >>> paths >>> to the LD_LIBRARY_PATH and restarted Tomcat (6.0.18). >>> >>> The message "The APR based Apache Tomcat Native library which allows optimal >>> performance in production environments was not found [...]" and I can see >>> the >>> paths to both libs in the java.library.path. >>> >>> I guess I have done something wrong. Any ideas? Can I change the logging >>> level >>> so I can get some more info in catalina.out? >>> >>> Torsten >>> >>> - >>> To start a new topic, e-mail: users@tomcat.apache.org >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >> >> -- >> Andrew R. Feller, Analyst >> Information Technology Services >> 200 Fred Frey Building >> Louisiana State University >> Baton Rouge, LA 70803 >> (225) 578-3737 (Office) >> (225) 578-6400 (Fax) >> >> >> - >> To start a new topic, e-mail: users@tomcat.apache.org >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > _ > You live life beyond your PC. So now Windows goes beyond your PC. > http://clk.atdmt.com/MRT/go/115298556/direct/01/ > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Andrew R. Feller, Analyst Information Technology Services 200 Fred Frey Building Louisiana State University Baton Rouge, LA 70803 (225) 578-3737 (Office) (225) 578-6400 (Fax) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSVC vs standard startup / shutdown scripts
Thanks for the response Torsten! In our environment, the machines we have Tomcat running on strictly use Tomcat 6, APR for SSL support, and we load balance applications through an external load balancer. We have been able to get by without brining HTTPD for things like mod_rewrite or any of the PAMs, so I would like to keep it as simple as possible. I don't have any personal issue with moving to running Tomcat directly as the non-privileged account meant for Tomcat, however I am curious about the trade offs especially related to security. Thanks! On 10/30/08 12:37 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Hi Andrew, > > We let all our Tomcats run on a non-privileged port and use some init script > using startup.sh/shutdown.sh, and have an Apache httpd forwarding requests > with AJP. > > We then use Apache httpd for things like terminating SSL, do RADIUS or LDAP > authentication, load balancing several Tomcat instances and so on. > > I think it is a good and common setup like that. > > Torsten > > -Original Message- > From: Andrew Feller [mailto:[EMAIL PROTECTED] > Sent: 30. oktober 2008 18:16 > To: users@tomcat.apache.org > Cc: Brad Cupit > Subject: JSVC vs standard startup / shutdown scripts > > QUESTION: What is the best practice for running Tomcat? JSVC daemon or > startup / shutdown scripts as a non-root user and forwarding HTTPS requests > to a non-privileged port? > > While reading the Professional Apache Tomcat 6 (ISBN: 978-0-471-75361-2), > they recommend running Tomcat to start it up using the startup script > provided in the Tomcat binary and having your firewall forward requests from > HTTPS to a non-privileged port. This is very interesting for two reasons: > >1. The book never mentions JSVC, which the Tomcat documentation does >2. We believed using JSVC was the only way to run as a non-root user, >which doesn't seem to be the case now > > I would appreciate any feedback about the trade offs and why people choose > one over the other. > > Thanks, > Andrew > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Andrew R. Feller, Analyst Information Technology Services 200 Fred Frey Building Louisiana State University Baton Rouge, LA 70803 (225) 578-3737 (Office) (225) 578-6400 (Fax) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem to install APR Tomcat Native Library
Torsten, Have you updated your LD_LIBRARY_PATH to include APR lib? A- On 10/30/08 12:15 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I am trying to install the APR Tomcat Native Library on a Solaris SPARC > server. > > Since it has only OpenSSL installed and no build system available, I compiled > libapr 1.3.3 and libtcnative 1.1.14 on another machine with the same OS. > > I then copied the lib folders of both libs to the server, and added the paths > to the LD_LIBRARY_PATH and restarted Tomcat (6.0.18). > > The message "The APR based Apache Tomcat Native library which allows optimal > performance in production environments was not found [...]" and I can see the > paths to both libs in the java.library.path. > > I guess I have done something wrong. Any ideas? Can I change the logging level > so I can get some more info in catalina.out? > > Torsten > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Andrew R. Feller, Analyst Information Technology Services 200 Fred Frey Building Louisiana State University Baton Rouge, LA 70803 (225) 578-3737 (Office) (225) 578-6400 (Fax) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possibility of JSVC daemon with APR reacting strangely to TCP health checks
After stepping through the tcpdump, we determined that the health checks are Layer 4 TCP health checks where the load balancer doesn't provide any HTTP request information whatsoever and closes the connection as soon as it is established. Here is the play-by-play of tcpdump: Source Destination DX APPL001 Frame 1 -SYN--> Frame 2 <--SYN,ACK- Frame 3 -ACK--> Frame 4 ---FIN,ACK> Frame 5I am currently checking on how the load balancer's Layer 7 health checks work, however it seems Tomcat with and without the JSVC daemon is reusing garbage in the event of empty Layer 4 health checks. Is this desired behavior? Is this necessarily a problem with Tomcat or could this be an issue with the version of tomcat-native distributed with Tomcat 6? Thanks! On 7/14/08 12:08 PM, "Len Popp" <[EMAIL PROTECTED]> wrote: > The obvious question is, are these TCP health checks well-formed HTTP requests > or not? I guess it's hard to snoop the exact contents of the request > since it's sent via SSL, but maybe you could configure it to send the > exact same health checks to port 80 via plain HTTP. Then you could > use Wireshark to see the exact contents of the requests, and figure out if the > problem is in the requests or in Tomcat. -- Len On Mon, Jul 14, 2008 at > 09:57, Andrew Feller <[EMAIL PROTECTED]> wrote: > Is there any reason > why Tomcat running under the JSVC daemon using the > Apache Portable Runtime > for SSL would act erratically to TCP health checks? > > We are using a Juniper > DX for load balancing that uses TCP health checks to > port 443 of a Tomcat > instance in order to keep the machine in the forwarding > cluster. However, > whenever the health check comes in, the logs generated by > Tomcat's > AccessLogValve show them to be malformed HTTP requests. My > networking > colleagues and the Juniper engineer confirm that it is sending > plain TCP > health checks; nothing fancy. As you can see in the logs below, > Tomcat > states the TCP health check is malformed HTTP request. Any thoughts? > > > Sincerely grateful for any assistance, > Andrew > > Environment: > >OS: > RHEL 5 32-bit >Tomcat: 6.0.14 >Connectors: Apache Portable Runtime > distributed with Tomcat binaries >Connector configuration: > > > protocol="org.apache.coyote.http11.Http11AprProtocol" > maxThreads="150" >SSLEnabled="true" scheme="https" secure="true" > clientAuth="false" > sslProtocol="TLS" > > SSLCertificateFile="/etc/pki/tls/certs/server.crt" > > SSLCertificateKeyFile="/etc/pki/tls/private/server.key" >/> > > > Excerpt from AccessLogValve output (with health check occurring every 9 > > seconds): > > 192.168.1.2 [07/Jul/2008:13:32:40 -0500] GET /serviceValidate > 200 240 - > serviceA.example.com 9 ?&someparam=1-f5dUkJr3KDo0VewDxeF7- > > serviceA.example.com&service=https%3A%2F%2serviceB.example.com%2Flogin > > > 192.168.1.2 [07/Jul/2008:13:32:40 -0500] > > H8f7UQt2SP-IeCHR0myAbQ0PyeXhTISx6ldp5RBOkd6GNkwfakOE6VGgFDyUr1wWWcVksPYbJSfD8B > qxjFHze8M0jGWn5dqfb3o0-VOovBOlsANm_lvjg7ZUEfz9ZFfo3RPxtt-qqP2hZNlynme7Dr62iBCq > 5K4DuryO4Dy3ne6uGizIIXkGIAf5OHU-sAMYnDnhi2IgB_IKIPwCqAA_DMwYfFRAuVwZ1X7GwcZZgP > MB8DnyhAUyFtyyK1cIqkH7b2HIhqFquoQJP2IhZbq-IfztVAQ4xzfDfXiDimop2AGuGK8aKhYWNhRM > uACscC7dKEKyUsJj9pFAzdZy8Rkl4MqqVbYyh-tsKhjgL2xEEofVw7WyADz5dwZvxX6CpewNhXxdks > NH39Rg7BvcokYFt5baJ_1hZeAH0ynn7lPTL4VYID4KKFZAf1IlUFd6jNJSMtD7GzidasfIlLO4Ds4b > 7Bg_leB4rX8biJBYPBB0_Fp8gBQLXyBpaIHHI47wgu-onISD6hGD-sbWumqSUvdikJUsrBCzuFuSWh > li4JceBwCdZqR3dRy3dxPNnQy1RsVtdkM1If8D5cdFIhgU4F2c1yVUZkOTYXklQ3NZ53BSnLMYnMKx > oRJ7P-1KYBjCZkMz8MynKcEMtUTFtq2AaMOsQ3qOnHjMvmxCiKv0N6tQRyHjrwgP8bfWE8Lk3z8x_q > gXc_UsD4-MeBayyhqbwl-m23xXw2IGVJ7B4Ul4JVHIhuP_9fv4AHsgw4noAAAM5UwMR1lWT_Dupw22 > 8eFXpuelprJzB4ilwXt3ey8IweBaiD84uB_zwhS3TAgG_ZKQVuOC6YJFbsXIWi59UdBBXncbhoxbXh > Rfn1DidZjHKvSyWXsuzaYsgaYSmDoWBKfn2Nyzq5dEi2ZwRwwQLyBQoJg8uj-9Q2ksayhmGbK8zWMc > FrPwMi3PwgNeru8GMu1EWw3IdNiM4CFEswnmNi_VSK1lr2oZXHKO6zOt58wW5eoFeXyifW42n3qq4x > pnOtAdx0NLYIcaVOfhcN8WRAxX_PGDwXrhqLM7HqaNyxl_V_SZ2U-DIsXTK9ds5dRzGD1NzFs6jTXH > kmFv5041Aq3OzGjpKjoE-IcjOutD7bNfHXV9DiwGdFuS6ONBZHO-m5GtwjOFpoVDXVZNiQIvKnxaUd > Fgeqgp1Yww15kHWrV7Z80jrPedydl6htlcSagGblsyzfJVVhBMrYx-3BQtC-JqKdkyQmahClMNlrOr > slNGqs3PQ4Ye8AIivjw21RP8qqMJksPx96hyqiy1szTa3eZRMkCANzvj1NWODhfzRZ9by50pLFnYRt > OM9XS0IdTB52NIdG4LRttvBnxE3GSGqNTTzkhXIDydZ5PuDF0rgzuhVAhHeKbuc3FgvPcaoBcKDJ4r > jFfmtJ79--vKvbn_tVzJVthjuf3mM19HEt5eCwzzYQB0m_j0hltGjx5pu4P985QUvYdbTIFQFxLsHT > 3174IqeVxNkMcjKZOYFVBT5ToLPx_4cWVv08mgygQ1zbbBm0Peuepm_0ZhpmPG3IJ4y_RAVBZXTWhV > SZL4s-EwlpZAknGdL1UVyYUm8SnLgwvQRg5l61WeecYaJPLn_zfJDH8G9valeooxNU9BOnPBtJ3737 > xcfzLzv7S5wnjbKUhRMWROs_Sf4FCZNVYqe_GjnC-dbT232tioZ9h6WPv7Wt-6ePNH_dFOz90EBDd4 > Qx7OWxmW-MEtWMC9zmLFLlpgky1UTc3gQZCZjbMvx > > 192.168.1.2 > [07/Jul/2008:13:32:49 -0500] GET /serviceValidate 200 240 - > > serviceA.exampl
Re: Mapping JSP's to outside of the war or expanded folder
We put a proxy in front of Tomcat. It serves all the static content. emerson cargnin wrote: Well, I said at the beginning that I'm not a big fan of this approach, but I understand the reasons behind it and the difficulties it would have to change it. Other reason for using this approach is when you have a great amount of static content, like images. An update of the war would have to include 1 or more giga of images and static html pages. What about if you have different applications (wars) that share common headers, footers, images, etc? Now people usually do it using symlinks, which makes it difficult using windows. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mapping JSP's to outside of the war or expanded folder
Right. The only way access to your servers is "totally strict" is if they have no network connection and no human input devices connected. However, in the "spirit" in which you probably meant this, I will have to point out that if your web apps are running on the internet then what you are requesting violates any competent security audit. If they are running on your local intranet then yes, it might not be a big deal. But even then, if the server could be used to get at personnel records or payroll, etc. then this could be just as big an issue. Ralph emerson cargnin wrote: This is not really an issue for me, as the access to the servers are totally strict and... any idea on how to map to the jsp's outside? Nobody ever need it? how do people migrate from resin then? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mapping JSP's to outside of the war or expanded folder
emerson cargnin wrote: We use windows on the dev workstatios and unix (SunOS 5.10 Generic_120011-14 sun4v sparc SUNW,Sun-Fire-T200) on dev/qa/production servers. We use Java 5 and we are migrating to tomcat 5.5 or 6. Ralph, why do you say it's dangerous? Even if it doesn't have java code, it would have tagslibs. Actually I don't really see any advantage using Velocity than JSP here. Since JSPs can contain any Java code, someone could put in code that does something completely unrelated to your application (send passwords or account information somewhere, etc). This is pretty hard to do without being detected when the JSPs are inside of a War file. When you put them outside of the war the controls are necessarily loosened because, presumably, you actually want people to be able to change these from time to time - so you may never know when one was changed inappropriately. With templates this can still happen, but since they can't add anything to a template that does more than change the view this isn't that dangerous. Ralph - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mapping JSP's to outside of the war or expanded folder
We have a similar need. But doing this with JSPs is very dangerous since they can have java code within them. Instead, using a templating language like Velocity would seem to be a mucn better approach. emerson cargnin wrote: The policy of our company is to deploy the jsp's separated from the war file, to allow a finer grained control over deployment. I'm not very fan of it, but it's something I won't be able to change. So I need a way to point the following URL's to another place in the file system. http://server/[context]/jsp/* http://server/[context]/css/* http://server/[context]/html/* http://server/[context]/images/* Thanks emerson On 18/02/2008, David Brown <[EMAIL PROTECTED]> wrote: Once the .war is expanded why would you want to map to JSPs outside of the file system package? emerson cargnin wrote .. Hi there We use resin here in my work. Resin allows in its web.xml an element like: /jsp/* c:/resin/resin-2.1.4/apps/ucs/ This can also be used in resin.conf, amking the war more portable. Now we are starting a migration to tomcat. But as far as I know TC doesnt not allow to have the JSP's out side of the war or the expanded war. I did a research a couple of years ago. Did it changed? Is there anyway now of mapping the jsp's of an app to an outside folder? Thanks Emerson Cargnin - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
unable to access Tomcat Admin
Hi I have a question about tomcat 5.5 admin pacakge. I downloaded it and installed it according to the instruction. After starting the tomcat server, when I click on the Tomcat Administration link, I got the following error message just like before Tomcat's administration web application is no longer installed by default. Download and install the "admin" package to use it I used the Manager and see the /admin was deployed and running. So instead of <http://localhost:8080/admin> http://localhost:8080/admin I typed <http://localhost:8080/admin/index.html> http://localhost:8080/admin/index.html, which mysteriously brought up the signon page for the Tomcat Web Server Administration Tool with the background in purple. I typed in the admin username and password and would get HTTP Status 404 - /admin/index.htmltype Status report message /admin/index.html description The requested resource (/admin/index.html) is not available. Now, after this, the link won't work anymore until the admin app is reloaded. I also added in the admin.xml (which the instruction didn't say) but it didn't help either Am I missing a step? Thanks Ralph
Re: Tomcat connections not closing.
Mike, Have you been able to make any progress with this? I'm very interested in the outcome as we experience the same problem. Ralph Roark, Mike wrote: Filip, Thanks for the help. You were right about the default for disableUploadTimeout. I must have been looking at 5.0 docs before, it looks like the default changed between 5.0 and 5.5. So I have now specified all three settings as you have them, and have had no effect. It seems like the socket remains open for as long as I feel like waiting. I have a perl script that will make a request and then not read the response (just sleeps), and another that will open a socket but not even write a GET line. Same result in both cases. I said that I could see the reads timeout, but now I'm not even seeing that. I would expect if I don't send a GET that the connectionTimeout would definitely apply. -Mike - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
