Re: Tomcat losing request parameters
Christopher,
All the parameters are lost when this issue occurs.
Code in the filter:
MapString, String[] paramMap = httpRequest.getParameterMap();
StringBuilder sb = new StringBuilder();
if(paramMap != null) {
sb.append(System.lineSeparator());
sb.append(Request URI: ).append(httpRequest.getRequestURI());
EnumerationString headerNames = httpRequest.getHeaderNames();
while(headerNames.hasMoreElements()){
String header = headerNames.nextElement();
sb.append(Request Header Name: ).append(header);
sb.append(, Request Header Value: ).append(httpRequest.getHeader(header));
sb.append(System.lineSeparator());
}
sb.append(System.lineSeparator());
for(Map.EntryString, String[] paramEntry : paramMap.entrySet()) {
sb.append(Param Name: ).append(paramEntry.getKey());
sb.append(, Param Values: ).append(paramEntry.getValue() != null ?
Arrays.asList(paramEntry.getValue()) : null);
sb.append(System.lineSeparator());
}
}
LOG.debug(Dumping request parameters: {}, sb.toString());
Regards,
Ravi
On Thu, Jun 4, 2015 at 9:54 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ravi,
On 6/4/15 11:40 AM, Ravi Kiran wrote:
Hi,
I am writing to get some pointers on a strange issue which are
facing in tomcat in one of our client environments.
Setup: 4 Webservers connecting to 2 tomcat using mod_jk (load
balanced)
Issue: Request parameters GET/POST are coming as null to the
application intermittently i.e, filter in web app dumps the request
parameters and finds everything empty. TCP dumps are inspected and
packets are reaching tomcat even during the failure cases.
Parameters are available in tcpdump but lost in between before it
reaches application. This happens only on one specific client
environment which makes it even difficult to isolate the problem.
Tomcat Version: 7.0.54
Please suggest some pointers to debug and resolve this issue. I can
provide more info if needed.
Can we see the code for your Filter?
Do all of the parameters appear to disappear, or only some of them?
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVcIKvAAoJEBzwKT+lPKRY6ioQALCHKEO/7Yj9RCkKXSPoBAOW
ayw8a0Pj802SwxTR1lBhvPf71ZiGqwmGv46a2ZxFDI+N6C0KB+6afI17XeoyjRKV
ieuBypeBpsYijVkwCHFICiwlF8U6fe2ar9KG+Vhjz/8DNweVXHtwRHDIK3G+
EQ22qGuyH5ydcw+e3M63hHGwHsLf3YK3akJR5soOAboHTbYADU374vqRmSWlRb70
Lcxq+691cvAbJH6yKen5oo9O+F2aMhMti/rvXrhSRQT2cfWQNKjLWIg7d3CPORsp
6FGpQieCJ/csO/2pBz4RKXopfGcybc5EGjh9uNgqQwmMtBoPHgTy1JWcumX80K3s
tYKYPcexR0qPpIEB76owAvbYUIgdlswhljYT8Wz7Fr7KZbxhFzoAhGSxitJHPgTC
kUmCrFW9ote9Xxn8tRHnVMvT45YVcA6i8vVLczKH/wzyAR/PVpgqI5Xrn+gMHDXH
Ld4XZYpc1xtT5bo1/QdRNoL9rl3TpJvbqCkfPfqNPCEv3vddzjmnmalJnvLbD/7C
Fvy639CaFqxl/0KNBcVsJdMg3JLnoaExa2UY5lpZA6L6rsqkYaQEBmfT97PKwaVp
Z7ftmW9bwTJ6BZArR3z4qEihWwm7AxNIk6sRO+Ef3tH0dIfqixClR+ccNZqNqvBP
fxboiBuGytLH5beNzUqi
=z+IM
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
systemd tomcat script for Linux EL7
Hi all, I am trying to put together a systemd script for an install of the current binary release tomcat7. Follows my current best effort, cobbled together from the (RH)EL7 packaged version and some googling... I am trying to use the unadulterated tomcat up/down scripts from the binary release. Any suggestions as to how this might be improved? I'm not sure if I am using the right service type here, based on what catalina.sh is doing under the hood. That said, it seems to work. Thanks Dale follows apache-tomcat.service # Systemd unit file for apache-tomcat # [Unit] Description=Apache Tomcat Web Application Container After=syslog.target network.target [Service] Type=forking PIDFile=/var/run/apache-tomcat/apache-tomcat.pid ExecStart=/opt/apache-tomcat/bin/startup.sh ExecStop=/opt/apache-tomcat/bin/shutdown.sh SuccessExitStatus=0 User=apache-tomcat Group=apache-tomcat [Install] WantedBy=multi-user.target * follows setenv.sh commented out sections removed # Where your java installation lives JAVA_HOME=/usr/java/latest # Where your tomcat installation lives CATALINA_BASE=/opt/apache-tomcat CATALINA_HOME=/opt/apache-tomcat CATALINA_OUT=/var/log/apache-tomcat/catalina.out JASPER_HOME=/opt/apache-tomcat CATALINA_TMPDIR=/opt/apache-tomcat/temp CATALINA_OPTS=-Xms1G -Xmx2G # What user should run tomcat TOMCAT_USER=apache-tomcat # Run tomcat under the Java Security Manager SECURITY_MANAGER=false # Time to wait in seconds, before killing process SHUTDOWN_WAIT=90 # Whether to annoy the user with attempting to shut down messages or not SHUTDOWN_VERBOSE=false # Set the TOMCAT_PID location CATALINA_PID=/var/run/apache-tomcat/apache-tomcat.pid # Connector port is 8080 for this tomcat instance CONNECTOR_PORT=8080 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] jar files - where - please explain
On 04/06/2015 17:31, Christopher Schultz wrote: snip/ We probably have a lot of places where we resolve filenames but I'm guessing we don't have a single utility method to do the work; Wrong :) probably just new File(new File(file).getCanonicalPath()) or something like that wherever it's needed. If we unified all those accesses in a single place, it would be easy to change these semantics for different environments. http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/web resources/AbstractFileResourceSet.java?view=annotate#l54 Nice work. So the code in there uses canonical paths, and when you canonicalize a symlink, you end up with the location of the real file, not the symlink, and everything goes boom at that point. Is my understanding correct? Correct. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat losing request parameters
On 04/06/2015 16:40, Ravi Kiran wrote: Hi, I am writing to get some pointers on a strange issue which are facing in tomcat in one of our client environments. Setup: 4 Webservers connecting to 2 tomcat using mod_jk (load balanced) Issue: Request parameters GET/POST are coming as null to the application intermittently i.e, filter in web app dumps the request parameters and finds everything empty. TCP dumps are inspected and packets are reaching tomcat even during the failure cases. Parameters are available in tcpdump but lost in between before it reaches application. This happens only on one specific client environment which makes it even difficult to isolate the problem. Tomcat Version: 7.0.54 Please suggest some pointers to debug and resolve this issue. I can provide more info if needed. Update to the latest 7.0.x release just in case there is something that has been fixed. It sounds like a timing issue. I'd be checking the app very carefully for how it handles request and response objects making sure they are not retained anywhere between requests. After that, I'd start adding debug log statements to the Tomcat source (probably not what you want to hear). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat losing request parameters
Hi, I am writing to get some pointers on a strange issue which are facing in tomcat in one of our client environments. Setup: 4 Webservers connecting to 2 tomcat using mod_jk (load balanced) Issue: Request parameters GET/POST are coming as null to the application intermittently i.e, filter in web app dumps the request parameters and finds everything empty. TCP dumps are inspected and packets are reaching tomcat even during the failure cases. Parameters are available in tcpdump but lost in between before it reaches application. This happens only on one specific client environment which makes it even difficult to isolate the problem. Tomcat Version: 7.0.54 Please suggest some pointers to debug and resolve this issue. I can provide more info if needed. Regards, Ravi
Re: Undefined symbol with native 1.1.33 and RHEL5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jesse, On 6/4/15 12:49 PM, Christopher Schultz wrote: Jesse, On 6/4/15 11:43 AM, Jesse Defer wrote: I am getting the following error from native on Tomcat startup: /usr/local/java/latest7/bin/java: symbol lookup error: /usr/local/apr/lib/libtcnative-1.so.0.1.33: undefined symbol: SSL_CTX_clear_extra_chain_certs SSL_CTX_clear_extra_chain_certs does not appear to be part of the RHEL5 distributed OpenSSL 0.9.8. There are no compile warnings/errors from native, RHEL5.11 Tomcat 6.0.44 APR 1.5.1 Have the OpenSSL version requirements changed? Are you sure your compile-time and run-time versions of OpenSSL are the same? I'm having trouble finding minimum-version information about SSL_CTX_clear_extra_chain_certs. Can you check in openssl.h (and whatever else it includes on your system) to see if that function is defined? On my Mac, I've got 0.9.8zd plus 1.0.1j and 1.0.2a. Only the 1.0.1 and 1.0.2 versions have that function defined, but it's actually a macro pointing to SSL_CTX_ctrl with some default parameters. So I'm surprised that you're seeing SSL_CTX_clear_extra_chain_certs being called a symbol, since the compiler should be replacing it with something else. Well, if it's not defined at all, it might assume it's a function with no prototype and just assume that at runtime things will work-out. Looks like not. Re-check your compiler logs: I think you'll find a warning about an unresolved symbol. Probably with the linker, too. But it will only be a warning, depending upon the compiler flags. sslutils:245 uses that macro: SSL_CTX_clear_extra_chain_certs(ctx); Perhaps we need to add a version-check around that, and then define the macro as OpenSSL does if necessary. Can you add a Bugzilla issue for this? Feel free to reference this mailing list thread. -chris In the meantime, can you throw this into tcnative.h at the bottom, and re-build everything? #define SSL_CTX_clear_extra_chain_certs(ctx) \ SSL_CTX_ctrl(ctx,SSL_CTRL_CLEAR_EXTRA_CHAIN_CERTS,0,NULL) See if that works for you. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVcIIeAAoJEBzwKT+lPKRYwdkP/3o1G+EtRRXMse5UI7+a2cU7 aRXcOQciDa9qbyDOFsNRWwayZuvK6yfE4JRXFfsBKlJ50Ec1alJd4dzqXz+BDsTx Q457uI07tr5pLZ+WMpUhlricmpGwD95b+UKWNrZX19D2ZZEHuhRuKwXsC2rSTq8D bhYxjihgbMQxRozfjfw9NbMnQ1ZJAHLm7TiTp9JbkSQKmYxQ3SnQ9QtTkLII8+yF WfOT7Y3bBeGpUPFN+/C335qAUQDkcx2iVlHUJfKeHIiy2XRv27D3/tkQM/9taAvD Xt5J1hjqKFmAn0IELHd/TEzeMiDPCKheE7UDURSgVTbg8zcHvzMQANRzg7b/DLBm XOTT9GAhJd8+ApqlfMuZidv6rxCcLsG7BZPXbnIYh6J0d21vjVGQCvPo0oCBi3/3 ymbZAkHzl1otfA7+fNyqG4oOOehCjGmwkev2qmrzyVTXRI2axFpWuDGbYTatGrWW 6wGTIBlJxhUCSxW4rK1kQEgWueyNTbG/Y/pHG7G4fdOYwsxRlT0MgRTj2CY/fvsS BmuCysD9VBuXMiWzc0V1Ixf19pBzX10qDlSBNPPpaeC36KJhAwwZDdEiDOFf+UtG NAGMy8Ig8zCPxXr4Guci7ps4MKKbbl5Zq5ND5hAqJxn/xqVBqRLh/lZDIks5Ozp3 7m3pDF3uM5n9sCzjBYjD =xQfW -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] jar files - where - please explain
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 6/4/15 3:15 AM, Mark Thomas wrote: On 03/06/2015 21:57, Christopher Schultz wrote: Mark, On 6/3/15 3:53 PM, Mark Thomas wrote: On 03/06/2015 20:48, Christopher Schultz wrote: snip/ I don't understand the underlying reasons why Tomcat treats symlinks specially... snip/ It is to do with case sensitivity on non case sensitive file systems. The check we have to add on Windows to stop things like JSP source disclosure by requesting /index.Jsp also blocks symlinks. Removing that check (and hence enabling symlinks) is safe on a case sensitive file system and unsafe on a non-case sensitive file system. Is that protection require something that can be detected by software, and then only applied when necessary? In theory, yes. In practise, given the security sensitivity of this I'd be very, very cautious about changing it. Agreed. There is probably some edge-case I'm not considering. ...but it *would* be nice to let symlinks work :) For instance, most UNIX filesystems have symlinks and case-sensitive filesystems, and these checks would not be necessary. Plus, users in those environments are quite used to using symlinks in place of real files. Windows users rarely use symbolic links, and have a case-sensitive filesystem, and these checks are certainly necessary. Prohibiting symbolic linking (by default) in this environment is probably okay. Mac OS X is a bit odd in that it's got all of the great things about a traditional UNIX filesystem except that it's got a better chance of being case-insensitive because HFS+ allows both semantics, but the default is unfortunately case-insensitive. In this environment, it's probably okay to prevent symbolic links unless he user forces them back on. The obvious way to check for case-sensitivity would be to create a file in the work directory with a certain name in mixed-case like TestFile.txt and then try to open it with an all-lowercase name (textfile.txt) and see if it exists. Then, we could enable or disable this kind of checking. Does anyone have any comments about something like that? We probably have a lot of places where we resolve filenames but I'm guessing we don't have a single utility method to do the work; Wrong :) probably just new File(new File(file).getCanonicalPath()) or something like that wherever it's needed. If we unified all those accesses in a single place, it would be easy to change these semantics for different environments. http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/web resources/AbstractFileResourceSet.java?view=annotate#l54 Nice work. So the code in there uses canonical paths, and when you canonicalize a symlink, you end up with the location of the real file, not the symlink, and everything goes boom at that point. Is my understanding correct? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVcH1nAAoJEBzwKT+lPKRYML8QAJJUxzgzTdrkvXHAF2W/OqKs yuca0UF0tGU72iPptVAF7Rsja1X+Bfi8V0SU7LWLtIP9VKaDTj1Vt2DNrCbArDPB lRMZlWNYBA/L/1HHh1wzk4CE1O5BcFQMUyKuzlvHFOhoN7LqSsiJoAPQLqrtM0rc 0VVtX51PBaB6QWzwwjTOUyJHto3CinPShekOhEUanSoSU5TO7wcpaqEwYK0YCZQx ATy0g7bg07RAfBzhZpgGmFzKDhIesNfD7RcCYYnktSr0LXIr8Onio+IQeyFjInGH bV5fSDaDmxlMvcWl8LrHtJqhw8B4qIKayXXtzeHongpgOKe6CsSLz8MaetWmb3QL 8S8IocN0XoLjegrWjmOyDNwRZo5/G9LpbFxBtMxY1uwW8pQ54Nk0hY5pAOcF8rGF B4gLxcAQy6L7Ml0ob26SdZufowy8QPgB8BGqHdH3jiUTiuoFoVX8QSXIEVnGqoy6 gxmvEjb6M5VkLkaib3F/4M+OSGg5n+ea45WqTUpLinfX37sC/HBL6bBrRRbFpAKk 30N8YOsblx4D2YbVe7M1HYvxcBOUoIBQxMSONg/VHArTgSdveA3BvhrHDOXY6WMf 6g/WTLNpHAaNBjlifRQCsCxr0wMAjGb8MFCxFDjDhR5Zz3VyWDCa0RWJ4UjfKIyj yRJd9Zxq45iPU0k7DBoD =2ME1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Undefined symbol with native 1.1.33 and RHEL5
I am getting the following error from native on Tomcat startup: /usr/local/java/latest7/bin/java: symbol lookup error: /usr/local/apr/lib/libtcnative-1.so.0.1.33: undefined symbol: SSL_CTX_clear_extra_chain_certs SSL_CTX_clear_extra_chain_certs does not appear to be part of the RHEL5 distributed OpenSSL 0.9.8. There are no compile warnings/errors from native, RHEL5.11 Tomcat 6.0.44 APR 1.5.1 Have the OpenSSL version requirements changed? Respectfully, Jesse DeFer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] jar files - where - please explain
From: Ray Holme [mailto:rayho...@yahoo.com.INVALID] Subject: Re: [OT] jar files - where - please explain I may be off base here, but IMHO Windoze does not support symbolic links Yes, you're off base. Windows symlinks have been available since Vista. GIYF. For example: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365680%28v=vs.85%29.aspx - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat losing request parameters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ravi, On 6/4/15 11:40 AM, Ravi Kiran wrote: Hi, I am writing to get some pointers on a strange issue which are facing in tomcat in one of our client environments. Setup: 4 Webservers connecting to 2 tomcat using mod_jk (load balanced) Issue: Request parameters GET/POST are coming as null to the application intermittently i.e, filter in web app dumps the request parameters and finds everything empty. TCP dumps are inspected and packets are reaching tomcat even during the failure cases. Parameters are available in tcpdump but lost in between before it reaches application. This happens only on one specific client environment which makes it even difficult to isolate the problem. Tomcat Version: 7.0.54 Please suggest some pointers to debug and resolve this issue. I can provide more info if needed. Can we see the code for your Filter? Do all of the parameters appear to disappear, or only some of them? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVcIKvAAoJEBzwKT+lPKRY6ioQALCHKEO/7Yj9RCkKXSPoBAOW ayw8a0Pj802SwxTR1lBhvPf71ZiGqwmGv46a2ZxFDI+N6C0KB+6afI17XeoyjRKV ieuBypeBpsYijVkwCHFICiwlF8U6fe2ar9KG+Vhjz/8DNweVXHtwRHDIK3G+ EQ22qGuyH5ydcw+e3M63hHGwHsLf3YK3akJR5soOAboHTbYADU374vqRmSWlRb70 Lcxq+691cvAbJH6yKen5oo9O+F2aMhMti/rvXrhSRQT2cfWQNKjLWIg7d3CPORsp 6FGpQieCJ/csO/2pBz4RKXopfGcybc5EGjh9uNgqQwmMtBoPHgTy1JWcumX80K3s tYKYPcexR0qPpIEB76owAvbYUIgdlswhljYT8Wz7Fr7KZbxhFzoAhGSxitJHPgTC kUmCrFW9ote9Xxn8tRHnVMvT45YVcA6i8vVLczKH/wzyAR/PVpgqI5Xrn+gMHDXH Ld4XZYpc1xtT5bo1/QdRNoL9rl3TpJvbqCkfPfqNPCEv3vddzjmnmalJnvLbD/7C Fvy639CaFqxl/0KNBcVsJdMg3JLnoaExa2UY5lpZA6L6rsqkYaQEBmfT97PKwaVp Z7ftmW9bwTJ6BZArR3z4qEihWwm7AxNIk6sRO+Ef3tH0dIfqixClR+ccNZqNqvBP fxboiBuGytLH5beNzUqi =z+IM -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jar files - where - please explain
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ray,
On 6/4/15 8:01 AM, Ray Holme wrote:
Inside the WAR or having the WAR as a symlnk?
OK, I did a test and YES inside a WAR file
${CATALINA_HOME}/webapps/Application/WEB-INF/lib/*.jarfiles ARE
expanded if they are symbolic links to real files.
What? The JAR utility does not support symlinks, so your JAR tool is
likely putting the whole file into the WAR archive.
Now, ZIP files *do* support symlinks, but I'll bet that Java will
fall-over if you try to open a ZIP file and it encounters a symlink in
there.
(My bad for not testing before). Now I am really in trouble. I
have an application which has a
${CATALINA_HOME}/webapps/Application/photosdirectory which is a
symbolic link
Pointing where?
with the following line in the
${CATALINA_HOME}/conf/Catalina/localhost/Application.xml file:
aliases=/photos=/opt/web_bigDirs/Applicationi_photos - I NEVER
wanted this link expanded!!!
Tomcat doesn't expand anything. If you have a WAR file with an alias
configured in it, it will just access the aliased directory directly.
The idea is to have multiple deployment places (hoping someday when
testing done), each having their own photos on file and never
deploy my own test photos.
Can you explain this in a little more detail? Remember that nobody
here has any idea what your application does, or what you expect to
happen.
I was assuming this would work.
Trust But Verify?
I tested and double DARN, jar cf expands the link pulling in all
the sub files - this totally frustrates my intention. I wanted a
symbolic link there for Unix based machines and just an empty
directory for Microsoft OS(s). Perhaps if I remove my symbolic
link the aliases parameter will work anyway.
The aliases setting is completely independent from any symlink
business you've got going on.
I will have to try that when I get a chance. I certainly don't
want to distribute the contents of this directory in a war file
(it could be HUGE).
I would just use the aliases setting and remove the symlink entirely.
The entire purpose of aliases is to allow you to have the effect of
symlinks, but do it in a safe way (that doesn't delete all your
symlinked files when you undeploy the web application, for instance).
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVcH7bAAoJEBzwKT+lPKRYwKEP/0nrcgRPykFIioBnPhPEUv1J
PeOpUpKrsSCHBjgIq691Bo1nZTWkdCAiplC/rBv7VRw3iW6d1oGkdQcK3xV66wiS
xlU2RwGfVYjau0Vbn/gTi4IimAMYYuzLWwYUOv9c9zNCcsctJlCVLksO9XDTHOdU
wl3D54WENVuAxFxP0P9iIoT1UEu0myAQHtcO0ez0uvdzt1DkaFR+EkJHDWcBPjPB
cqvHXOYHzR6Ixv4Z3t+8DprmPHgIHQxjPlt4OhEIgGFqE0q1oDA6VKjdDcRETdQB
Q0v6eynBC43w7Ac61R6KU6zNXxpxTWL+8+xZ9dqAy8zlJmsDqLUXt8SkDGc9mkJR
lcELbmfKttsHIgoVydyBjS8WyvpAYYkS8MLj/ntpb1w7lWuKHV6tHkcyX2pSfOEG
g1sMUU8P4/rCrFk69/1GJkP9DUL1nfIskGybQ1cTPuBs5m1tPIgVVhSf8swOLdYl
6tkG+9+H8x8ICW/kuggSmiD8aKpl3+NBmfxRhzUJBNSDUDIsyGCp4vT2usAExyu4
SEaC5XlB18uNvIoZrDWx7naodWiMRIgTCno0cJyNgq+NpxlRJ7NbOHpa8xzwK0gV
RG1vzP6jvSxIHioIk/W+R7+hiWU2DyzePAIhVsCTcvf96CmMuYtub3x+WYF5vEnM
ZCBcvR4CU2ba0oIZQcXB
=N8tQ
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Undefined symbol with native 1.1.33 and RHEL5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jesse, On 6/4/15 11:43 AM, Jesse Defer wrote: I am getting the following error from native on Tomcat startup: /usr/local/java/latest7/bin/java: symbol lookup error: /usr/local/apr/lib/libtcnative-1.so.0.1.33: undefined symbol: SSL_CTX_clear_extra_chain_certs SSL_CTX_clear_extra_chain_certs does not appear to be part of the RHEL5 distributed OpenSSL 0.9.8. There are no compile warnings/errors from native, RHEL5.11 Tomcat 6.0.44 APR 1.5.1 Have the OpenSSL version requirements changed? Are you sure your compile-time and run-time versions of OpenSSL are the same? I'm having trouble finding minimum-version information about SSL_CTX_clear_extra_chain_certs. Can you check in openssl.h (and whatever else it includes on your system) to see if that function is defined? On my Mac, I've got 0.9.8zd plus 1.0.1j and 1.0.2a. Only the 1.0.1 and 1.0.2 versions have that function defined, but it's actually a macro pointing to SSL_CTX_ctrl with some default parameters. So I'm surprised that you're seeing SSL_CTX_clear_extra_chain_certs being called a symbol, since the compiler should be replacing it with something else. Well, if it's not defined at all, it might assume it's a function with no prototype and just assume that at runtime things will work-out. Looks like not. Re-check your compiler logs: I think you'll find a warning about an unresolved symbol. Probably with the linker, too. But it will only be a warning, depending upon the compiler flags. sslutils:245 uses that macro: SSL_CTX_clear_extra_chain_certs(ctx); Perhaps we need to add a version-check around that, and then define the macro as OpenSSL does if necessary. Can you add a Bugzilla issue for this? Feel free to reference this mailing list thread. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVcIGMAAoJEBzwKT+lPKRYw08P/icdrYqC64xnIkSLoXr7JIqb 6hB2efkSbGT9QMZRAcfLyV8rD0m+qdj9X2qh+Bak2kMpvSjZ6lhTgo+NcVY9Ns0a FddZg/tXzl8qmoK1V7RsT0/zJ8lguWZ2uLbZw+aTZMBHyI1Co6Hy8owglKFQrePs HreWGDtEHFjhZsqHE8DlNjl+usXC0gNHTNn8V2orlyk0zrfLyoaBeD0fpwlMRy3m KhJ5y6KvlXmP0pjqJyWeddJiDoEWALnIooewddJJ/B5XfHkC5P4OIQZ0jtFYpC+D fLFV5INK8RKcwI9bPezWJ8glnKr9xZvz/l6fb+cDbliMYaOePA/33sFbvC7ZoC2/ CYzexNUBd2642+4ttdPSW67ifmex6WRoam9AHbSTA0Y8UGOEuRTlNp3i7k+IVs0u ywi1AeTx+D/v/VUgoY8++WT30Il8NcldJStOhlz2/zYOCLdtWRTiBzAoSBCpqerh 9AluB7glhYerjYLRJ8aSxfr6o3jESORi6MqgL9Bn2gXmWmvUCCs93W2xAMrXI8IH CYrjcLVcPTWgrZ+arwhEO57VTyIyGmbA/0pSJhSBpIv6kJ54Xq1aHm62zXb90RZ+ Rimal9N3p/fB5pIc/I0fiW4gRhY2S2MIksM+e3sq1CmPQYDVEZTr73XZoj+M6u0a G167bznhuNZz7PAG1/fA =UDm6 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] jar files - where - please explain
For instance, most UNIX filesystems have symlinks and case-sensitive filesystems, and these checks would not be necessary. Plus, users in those environments are quite used to using symlinks in place of real files. Using Unix and Linux for a LONG time, love symlinks as they work across file systems and oh so much more. Windows users rarely use symbolic links, and have a case-sensitive filesystem, and these checks are certainly necessary. Prohibiting symbolic linking (by default) in this environment is probably okay. I may be off base here, but IMHO Windoze does not support symbolic links, or fork or ...It is more like a partial Unix (was built on the idea, but not fully formed). Mac OS X is a bit odd in that it's got all of the great things about a traditional UNIX filesystem except that it's got a better chance of being case-insensitive because HFS+ allows both semantics, but the default is unfortunately case-insensitive. In this environment, it's probably okay to prevent symbolic links unless he user forces them back on. Not a big user of OSX - not aware it supported case-insensitive. When I used it I treated it like Unix with case sensitive files and had NO problems. The obvious way to check for case-sensitivity would be to create a file in the work directory with a certain name in mixed-case like TestFile.txt and then try to open it with an all-lowercase name (textfile.txt) and see if it exists. Then, we could enable or disable this kind of checking. Sounds like the right approach. On Thursday, June 4, 2015 12:32 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 6/4/15 3:15 AM, Mark Thomas wrote: On 03/06/2015 21:57, Christopher Schultz wrote: Mark, On 6/3/15 3:53 PM, Mark Thomas wrote: On 03/06/2015 20:48, Christopher Schultz wrote: snip/ I don't understand the underlying reasons why Tomcat treats symlinks specially... snip/ It is to do with case sensitivity on non case sensitive file systems. The check we have to add on Windows to stop things like JSP source disclosure by requesting /index.Jsp also blocks symlinks. Removing that check (and hence enabling symlinks) is safe on a case sensitive file system and unsafe on a non-case sensitive file system. Is that protection require something that can be detected by software, and then only applied when necessary? In theory, yes. In practise, given the security sensitivity of this I'd be very, very cautious about changing it. Agreed. There is probably some edge-case I'm not considering. ...but it *would* be nice to let symlinks work :) For instance, most UNIX filesystems have symlinks and case-sensitive filesystems, and these checks would not be necessary. Plus, users in those environments are quite used to using symlinks in place of real files. Windows users rarely use symbolic links, and have a case-sensitive filesystem, and these checks are certainly necessary. Prohibiting symbolic linking (by default) in this environment is probably okay. Mac OS X is a bit odd in that it's got all of the great things about a traditional UNIX filesystem except that it's got a better chance of being case-insensitive because HFS+ allows both semantics, but the default is unfortunately case-insensitive. In this environment, it's probably okay to prevent symbolic links unless he user forces them back on. The obvious way to check for case-sensitivity would be to create a file in the work directory with a certain name in mixed-case like TestFile.txt and then try to open it with an all-lowercase name (textfile.txt) and see if it exists. Then, we could enable or disable this kind of checking. Does anyone have any comments about something like that? We probably have a lot of places where we resolve filenames but I'm guessing we don't have a single utility method to do the work; Wrong :) probably just new File(new File(file).getCanonicalPath()) or something like that wherever it's needed. If we unified all those accesses in a single place, it would be easy to change these semantics for different environments. http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/web resources/AbstractFileResourceSet.java?view=annotate#l54 Nice work. So the code in there uses canonical paths, and when you canonicalize a symlink, you end up with the location of the real file, not the symlink, and everything goes boom at that point. Is my understanding correct? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVcH1nAAoJEBzwKT+lPKRYML8QAJJUxzgzTdrkvXHAF2W/OqKs yuca0UF0tGU72iPptVAF7Rsja1X+Bfi8V0SU7LWLtIP9VKaDTj1Vt2DNrCbArDPB lRMZlWNYBA/L/1HHh1wzk4CE1O5BcFQMUyKuzlvHFOhoN7LqSsiJoAPQLqrtM0rc 0VVtX51PBaB6QWzwwjTOUyJHto3CinPShekOhEUanSoSU5TO7wcpaqEwYK0YCZQx ATy0g7bg07RAfBzhZpgGmFzKDhIesNfD7RcCYYnktSr0LXIr8Onio+IQeyFjInGH
Re: Tomcat JDBC vs DBCP2?
On 03.06.2015 21:57, Mark Thomas wrote: On 03/06/2015 20:50, Christopher Schultz wrote: Bjørn, On 6/3/15 2:52 PM, Bjørn T Johansen wrote: Just saw a discussion about Tomcat DBCP 8.0.18 issue, where Tomcat JDBC pooling vs Commons DBCP 2 pooling was briefly discussed.. So now I am a bit curious... I am using Tomcat JDBC, because I read somewhere that this was better than DBCP (guess they were talking about DBCP 1 then). Does this mean I should be using DBCP 2 instead of Tomcat JDBC with my Tomcat 8.x installations? If it ain't broke, don't fix it. Because of it being the default in Tomcat, DBCP2 is likely to have much more mileage under its belt than tomcat-jdbc, so edge cases and strange issues are more likely to be discovered and solved. It is probably around 50/50 at the moment since tomcat-jdbc has been around longer but at the moment the balance is shifting towards DBCP2. If you want to know about performance, you'll have to benchmark in your own environment -- and make sure you use a valid test case. Don't just test how long it takes to check-out 1M connections and return them to the pool in a single thread. +1. In terms of raw speed for default settings tomcat-jdbc will be faster. Once you configure them for comparable behaviour the difference is a lot less. I think it's a matter of preference for the most part. At the moment, yes. If I were you, I'd stick with my existing configuration, if only because you know it works. ;) +1 Longer term, I'd be looking towards DBCP 2 - mainly because of the general lack of activity on tomcat-jdbc. Mark Ok... Guess I'll continue using Tomcat JDBC for now but change to DBCP 2 when I get the time to test Thx... :) BTJ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] jar files - where - please explain
On 03/06/2015 21:57, Christopher Schultz wrote: Mark, On 6/3/15 3:53 PM, Mark Thomas wrote: On 03/06/2015 20:48, Christopher Schultz wrote: snip/ I don't understand the underlying reasons why Tomcat treats symlinks specially... snip/ It is to do with case sensitivity on non case sensitive file systems. The check we have to add on Windows to stop things like JSP source disclosure by requesting /index.Jsp also blocks symlinks. Removing that check (and hence enabling symlinks) is safe on a case sensitive file system and unsafe on a non-case sensitive file system. Is that protection require something that can be detected by software, and then only applied when necessary? In theory, yes. In practise, given the security sensitivity of this I'd be very, very cautious about changing it. For instance, most UNIX filesystems have symlinks and case-sensitive filesystems, and these checks would not be necessary. Plus, users in those environments are quite used to using symlinks in place of real files. Windows users rarely use symbolic links, and have a case-sensitive filesystem, and these checks are certainly necessary. Prohibiting symbolic linking (by default) in this environment is probably okay. Mac OS X is a bit odd in that it's got all of the great things about a traditional UNIX filesystem except that it's got a better chance of being case-insensitive because HFS+ allows both semantics, but the default is unfortunately case-insensitive. In this environment, it's probably okay to prevent symbolic links unless he user forces them back on. The obvious way to check for case-sensitivity would be to create a file in the work directory with a certain name in mixed-case like TestFile.txt and then try to open it with an all-lowercase name (textfile.txt) and see if it exists. Then, we could enable or disable this kind of checking. Does anyone have any comments about something like that? We probably have a lot of places where we resolve filenames but I'm guessing we don't have a single utility method to do the work; Wrong :) probably just new File(new File(file).getCanonicalPath()) or something like that wherever it's needed. If we unified all those accesses in a single place, it would be easy to change these semantics for different environments. http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java?view=annotate#l54 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FormAuthenticator, Tomcat restart
On Fri, May 29, 2015 at 9:47 AM, André Warnier a...@ice-sa.com wrote: 20-odd Well the development team uses Tomcat via Eclipse and after changing some code they do Tomcat restart because more often than not, hot redeploy doesn't give good results. That's why Tomcat restart is a RATHER often event during the development (maybe we're doing something wrong that's why hot redeploy doesn't work as expected). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] jar files - where - please explain
Inside the WAR or having the WAR as a symlnk?
OK, I did a test and YES inside a WAR file
${CATALINA_HOME}/webapps/Application/WEB-INF/lib/*.jarfiles ARE expanded if
they are symbolic links to real files. (My bad for not testing before).Now I am
really in trouble. I have an application which has a
${CATALINA_HOME}/webapps/Application/photosdirectory which is a symbolic link
with the following line in the
${CATALINA_HOME}/conf/Catalina/localhost/Application.xmlfile:
aliases=/photos=/opt/web_bigDirs/Applicationi_photos - I NEVER wanted this
link expanded!!!The idea is to have multiple deployment places (hoping someday
when testing done), each having their own photos on file and never deploy my
own test photos. I was assuming this would work. I tested and double DARN, jar
cf expands the link pulling in all the sub files - this totally frustrates my
intention. I wanted a symbolic link there for Unix based machines and just an
empty directory for Microsoft OS(s). Perhaps if I remove my symbolic link the
aliases parameter will work anyway. I will have to try that when I get a
chance. I certainly don't want to distribute the contents of this directory
in a war file (it could be HUGE).
On Thursday, June 4, 2015 3:15 AM, Mark Thomas ma...@apache.org wrote:
On 03/06/2015 21:57, Christopher Schultz wrote:
Mark,
On 6/3/15 3:53 PM, Mark Thomas wrote:
On 03/06/2015 20:48, Christopher Schultz wrote:
snip/
I don't understand the underlying reasons why Tomcat treats
symlinks specially...
snip/
It is to do with case sensitivity on non case sensitive file
systems. The check we have to add on Windows to stop things like
JSP source disclosure by requesting /index.Jsp also blocks
symlinks.
Removing that check (and hence enabling symlinks) is safe on a
case sensitive file system and unsafe on a non-case sensitive file
system.
Is that protection require something that can be detected by software,
and then only applied when necessary?
In theory, yes.
In practise, given the security sensitivity of this I'd be very, very
cautious about changing it.
For instance, most UNIX filesystems have symlinks and case-sensitive
filesystems, and these checks would not be necessary. Plus, users in
those environments are quite used to using symlinks in place of real
files.
Windows users rarely use symbolic links, and have a case-sensitive
filesystem, and these checks are certainly necessary. Prohibiting
symbolic linking (by default) in this environment is probably okay.
Mac OS X is a bit odd in that it's got all of the great things about a
traditional UNIX filesystem except that it's got a better chance of
being case-insensitive because HFS+ allows both semantics, but the
default is unfortunately case-insensitive. In this environment, it's
probably okay to prevent symbolic links unless he user forces them
back on.
The obvious way to check for case-sensitivity would be to create a
file in the work directory with a certain name in mixed-case like
TestFile.txt and then try to open it with an all-lowercase name
(textfile.txt) and see if it exists. Then, we could enable or
disable this kind of checking.
Does anyone have any comments about something like that?
We probably have a lot of places where we resolve filenames but I'm
guessing we don't have a single utility method to do the work;
Wrong :)
probably just new File(new File(file).getCanonicalPath()) or something
like that wherever it's needed. If we unified all those accesses in a
single place, it would be easy to change these semantics for different
environments.
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/webresources/AbstractFileResourceSet.java?view=annotate#l54
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
