Re: Finding the Apache httpd IP address when AJP is used
Paul Klinkenberg wrote: Hi Christopher, Thanks for taking the time to respond; again much appreciated. Your point, and André's, is understood. Security should not be done based on incoming IP address. With this current project, we off course want to deliver software which is secure by default. Now, if someone would install Tomcat, then add the mod_cfml valve, and then doesn't lock port 8080 or 8009, the server would become vulnerable in the same way as if the /host-manager would not have password-protection. Currently, I am discussing with the main mod_cfml developers Jordan Michaels and Bilal Soylu how to implement security, since I now won't be implementing IP restriction. We'll probably go with using the secret configuration parameter for ajp like you suggested. Or maybe using a shared secret key between the frontend server and the Tomcat valve. In this last case, we would also have tackled security when remote attackers try to contact Tomcat on http-8080 directly, instead of using the ajp connector. I never knew the remote_addr could not be trusted, but I believe you at once when you say so. I thought it was taken from the actual socket connection. With the exception of ajp by the way, where it is programmatically changed to reflect the remote client while handling the http call. Out of curiosity, could you shed some light as to why the remote_addr is not to be trusted in a regular http request? Thanks again for your time and effort! Kind regards, Paul Klinkenberg On Tomcat, you can set the AJP Connector to only listen on the local IP address of the Tomcat server host. That means that only local LAN clients (including the httpd front-end, presumably) can connect to that Connector. So this already stops any external client (be it workstation or server) from even connecting to Tomcat using AJP. It also, presumably, insures that only your internal httpd front-ends can potentially connect to Tomcat via AJP. Now if you do not even trust your internal servers/clients, /then/ you need additional measures. But in such a case, whether you use a secret which the front-end must provide, or whether you use an additional header or Jk variable, is only a choice; but any of those requires some setup on the front-ends. The same is for the other Connectors, like HTTP/HTTPS. If you do not want people to connect through these, disable them or have them also only listen on a local IP address. Op 29 apr. 2015, om 17:48 heeft Christopher Schultz ch...@christopherschultz.net het volgende geschreven: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Paul, On 4/29/15 11:17 AM, Paul Klinkenberg wrote: The reason I want to add the IP restriction in the valve, is to make 100% sure that the request (for creating a new Tomcat context) is indeed coming from the frontend webserver. I think there are better ways to do this. Among them: 1. Firewall rule that only allows access to the AJP port from a certain IP address/range. 2. Use of the secret configuration parameter for mod_jk/AJP connector In production, we tunnel AJP from our web servers to our application servers using stunnel, and stunnel connections are only allowed from the range of IPs used by our web servers. Then, we actually have the AJP connector listen on ::1 so nobody from the outside can connect to us, except through such a tunnel. This valve is a setup not just for me, where I could tweak server settings and such, but for anyone who uses the mod_cfml connector. It is installed by default by the Railo/Lucee installers (getrailo.org http://getrailo.org/ / lucee.org http://lucee.org/) It seems a little fragile, because it requires configuration beyond what an installer can auto-configure for you (i.e. it has no idea what the IP address of the web server(s) is(are)). Therefor, I cannot rely on an incoming header, as it could originate from anywhere. Also, a remote system could call the AJP endpoint on the Tomcat server, with this JkEnvVar set to a spoofed value. (if the port is not firewalled off course) So the problem with both options is, that they cannot be fully trusted. If you are that paranoid, you also can't trust the source IP address in the IP header, so you are back to square 1: you can't trust anything, so don't build your security around this lack-of-trust. If I am able to find out where the AJP request came from, then I can validate the caller. The only way to check the caller would be to get ahold of the Socket that Tomcat is using to communicate. That's not easily done, since Tomcat wants to protect its sockets from code messing-around with the state of those Sockets. If you don't trust mod_jk to send you the right values, then you also can't trust the REMOTE_ADDR value that is pointing to the real client. Basically, it comes down to this: you either trust mod_jk or not. If you don't, then all bets are off. If you *can* trust mod_jk, then just forward an environment variable using JkEnvVar:
Re: File descriptors peaks with latest stable build of Tomcat 7
Thanks for your reply, we'll give a try to your suggestions. 2015-04-29 23:15 GMT+02:00 Christopher Schultz ch...@christopherschultz.net : -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thomas, On 4/25/15 4:25 AM, Thomas Boniface wrote: When talking about the strategy for our next test on the release we checked at the tomcat connector configuration but we are unsure how to applies your advices: 1. Check the nginx configuration. Specifically, the keep-alive and timeout associated with the proxy configuration. 2. Make sure that Tomcat's timeouts are appropriate for those matching settings in nginx. It seems were have 100 connections max keept alive at nginx level ( keepalive), a timeout to connect to tomcat of 2s (proxy_connect_timeout) and a timeout to read from tomcat of 10s (proxy_read_timeout). On tomcat side we have a connector like follows: Connector port=8080 protocol=org.apache.coyote.http11.Http11NioProtocol selectorTimeout=1000 maxThreads=200 maxHttpHeaderSize=16384 address=127.0.0.1 redirectPort=8443/ It sounds like you need to add this to your Connector configuration: connectionTimeout=1 This matches your value for proxy_read_timeout. You should probably also set keepAliveTimeout if you think it needs to be different from connectionTimeout (keepAliveTimeout defaults to connectionTimeout). I'm not sure if Nginx's proxy_read_timeout is the same timeout used to terminate a connection to Tomcat if Nginx hasn't tried to send a request over that connection for a while, but if so, the connectionTimeout/keepAliveTimeout is what you want to set. I'm not sure that setting selectorTimeout to something other than the default helps you at all (1000ms is the default). The goal is to get both Nginx and Tomcat to close their connections at the same time when they decide that the connection is no loner necessary. If Nginx times-out more quickly than Tomcat, then re-opens a new connection to Tomcat, it will make Tomcat artificially run out of connections (and file descriptors) even though Tomcat is largely idle . - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVQUnhAAoJEBzwKT+lPKRYzZwQAIgYxw6OuCgPeks/1S8x7bVP MdBdLddY9ruDNCRq9kLzKxEouo/WD5zuQW3kMRyTlX9I36HVRRcE6boaIwFBjiws LhoEMy6f5cZQj0FzRfstmyiyOFmZKtvAxwMVa8p1ykqkAhysDTU4fDKxmsKDk1fM fakJkqj4nRYP86ekFq/kIb/TNdMbzq+qx32QlevB/z+p0t7frR1DXadRK5KGXGVu dOHclY3Z29nzIGe+hdZULkZgpmAUDtk+Y7/bePeWv7ln6IBBoka7hYZGLj1+shdy PHrWs0ikTKTB9+kgS7OaipZD8r8x0yvtYYTEjZt3Jcsno0W2kKW600oTFI9YFJ2M XDu87+TUvb+E/NYLjJIPQICtDK71b0JpPt8ijQCx+91RFiFRYS8tuWNABcWbtRBb C2WlHmNilI/i+kAc7Syvao9gKO594jpao4nlPWhOXJK75QDw5K1szgo/ONgwujtU YRtpyZCVVB8UCUk8QIESL8WQT7zlP4MDlEpmeyRzhEGRcelCMoXEq22rZ4HVygAP iZg8KbkwUN/Ul7FMcwBbxoWOVE9iTBEj2nHuriAH5oKPnSJbuI2lfxOpxKSVMQaI NKV8Zb+yNby11UWWQxxI0QaStZB9IMVnCTLEMXT/M/okwd12xZKuChhh6RFaXKxL WIZLFHnxc4C5yWay7OPx =tLMj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Finding the Apache httpd IP address when AJP is used
Hi Christopher, Thanks for taking the time to respond; again much appreciated. Your point, and André's, is understood. Security should not be done based on incoming IP address. With this current project, we off course want to deliver software which is secure by default. Now, if someone would install Tomcat, then add the mod_cfml valve, and then doesn't lock port 8080 or 8009, the server would become vulnerable in the same way as if the /host-manager would not have password-protection. Currently, I am discussing with the main mod_cfml developers Jordan Michaels and Bilal Soylu how to implement security, since I now won't be implementing IP restriction. We'll probably go with using the secret configuration parameter for ajp like you suggested. Or maybe using a shared secret key between the frontend server and the Tomcat valve. In this last case, we would also have tackled security when remote attackers try to contact Tomcat on http-8080 directly, instead of using the ajp connector. I never knew the remote_addr could not be trusted, but I believe you at once when you say so. I thought it was taken from the actual socket connection. With the exception of ajp by the way, where it is programmatically changed to reflect the remote client while handling the http call. Out of curiosity, could you shed some light as to why the remote_addr is not to be trusted in a regular http request? Thanks again for your time and effort! Kind regards, Paul Klinkenberg Op 29 apr. 2015, om 17:48 heeft Christopher Schultz ch...@christopherschultz.net het volgende geschreven: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Paul, On 4/29/15 11:17 AM, Paul Klinkenberg wrote: The reason I want to add the IP restriction in the valve, is to make 100% sure that the request (for creating a new Tomcat context) is indeed coming from the frontend webserver. I think there are better ways to do this. Among them: 1. Firewall rule that only allows access to the AJP port from a certain IP address/range. 2. Use of the secret configuration parameter for mod_jk/AJP connector In production, we tunnel AJP from our web servers to our application servers using stunnel, and stunnel connections are only allowed from the range of IPs used by our web servers. Then, we actually have the AJP connector listen on ::1 so nobody from the outside can connect to us, except through such a tunnel. This valve is a setup not just for me, where I could tweak server settings and such, but for anyone who uses the mod_cfml connector. It is installed by default by the Railo/Lucee installers (getrailo.org http://getrailo.org/ / lucee.org http://lucee.org/) It seems a little fragile, because it requires configuration beyond what an installer can auto-configure for you (i.e. it has no idea what the IP address of the web server(s) is(are)). Therefor, I cannot rely on an incoming header, as it could originate from anywhere. Also, a remote system could call the AJP endpoint on the Tomcat server, with this JkEnvVar set to a spoofed value. (if the port is not firewalled off course) So the problem with both options is, that they cannot be fully trusted. If you are that paranoid, you also can't trust the source IP address in the IP header, so you are back to square 1: you can't trust anything, so don't build your security around this lack-of-trust. If I am able to find out where the AJP request came from, then I can validate the caller. The only way to check the caller would be to get ahold of the Socket that Tomcat is using to communicate. That's not easily done, since Tomcat wants to protect its sockets from code messing-around with the state of those Sockets. If you don't trust mod_jk to send you the right values, then you also can't trust the REMOTE_ADDR value that is pointing to the real client. Basically, it comes down to this: you either trust mod_jk or not. If you don't, then all bets are off. If you *can* trust mod_jk, then just forward an environment variable using JkEnvVar: that technique can't be modified by the client injecting an HTTP header or anything like that. But of course, you still have to trust mod_jk and the connection the request came from. This is what the firewall should be used for, IMO. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVQP1VAAoJEBzwKT+lPKRYkcwQAKEJ4L4xqd7h2TRoA0TaAZYk MsnpJy9fKSOB+18jAgN8d1vcctV9+zabgRqT+BhK6rArc3RcaO4puLgNe2k3IduH AMHXQARLyYFSH42q7cAFyiRV5jVhDdTKr+pEhKTNbXdwdoOxPQMknTpfK01ESPkA kVAKWnT2GdLq9eo3nSGlTXyKJrBLNPa2LhHHQXmc/VaSIO6wFR3pEP/DkoOdU430 QVmDinvruNEvSSNf0ef8UTeBhLOYFb099GfIOFq57r46B5s63469yQCwRrCKK7c9 g89Xm8j44TI445nj1J7BpbHfwLZxFsKRVwln2MZ0RKxX7ow/Zs/teQj7FpG6pbr2 7RGPi7jn0bo5GVe15S8cQMhPt7144FwuO97dhzPPUD+Dqv6hXuuNO92uJbDjllCl GW5pzhHqKZ7BJ54q6RZsreArz/PRE+Cih/fs+MhjmHy6W/Aj5HeOVF8aJmn4/KvZ
unable to install tomcat7 on windows 2012 --- getting access denied
Hi: I'm installing tomcat7 as a service on windows 2012 using the following command: Service.bat install I get an access denied message. I'm and admin on the server as well as running the command from a command prompt as admin. Any idea what may be blocking me?
Re: Exception in Tomcat7 when closing stream, server crashes
Just an update. We have been doing some testing and we might not be seeing Tomcat actually go down with 7.0.61. The errors are still occurring but it is possible it may not be crashing. We were seeing the crash with 7.0.56. I’ll post an update once have done some more thorough testing. Thanks -- Osman Ullah Tech Lead, Software Engineering Ntrepid Corporation, Herndon, VA (t) 571.612.8386 osman.ul...@ntrepidcorp.com On 4/29/15, 5:33 PM, Osman Ullah | Ntrepid Corp osman.ul...@ntrepidcorp.com wrote: On 4/29/15, 4:39 PM, Christopher Schultz ch...@christopherschultz.net wrote: When you say that Tomcat crashes, are you saying that the JVM halts with an hs_err_[pid] file, or do you mean you get the above stack traces (which are errors, I would not call them crashes). What exact version of tcnative are you using? APR? What OS are you using ? Can you switch to the NIO connector temporarily to see if those problems go away? It's possible that this is only a problem with the APR connector. - -chris Thanks for the response Chris, Yes, eventually it crashes with a hs_err file and has to be restarted. The errors do not show up when we use NIO so I am pretty sure it¹s a problem in the APR connector somewhere. APR based Apache Tomcat Native library 1.1.33 using APR version 1.5.1. OS is Centos 6.4. Thanks smime.p7s Description: S/MIME cryptographic signature
Re: unable to install tomcat7 on windows 2012 --- getting access denied
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Eric, On 4/30/15 9:33 AM, Eric Wood wrote: I'm installing tomcat7 as a service on windows 2012 using the following command: Service.bat install I get an access denied message. I'm and admin on the server as well as running the command from a command prompt as admin. Any idea what may be blocking me? As someone who knows little to nothing about Microsoft Windows administration... Are you a local administrator, or a network administrator? If you are on a network with a domain controller, are there different rules about who can do what? It's possible that a local administrator may not be able to install services, for instance. I could also have absolutely no idea what I'm talking about. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVQjnEAAoJEBzwKT+lPKRYT2sQAKrWtNjAofyxpVt6WDbrH8nO A35RKSxa6k9eUtpaRxQs2RVcTXilc//UMBw4GWFY2KdUdm2xgs1jDwxVADWJvxi9 E9kqNTtAMNzxZDhlizXVzpe/LrAzpEvBs1jnYgEsLn7aLBHh9RLb7PVhi06o1K2d WquVqUpjRpFLVB187qI1BhIgTGCebNK5KoTza7s4vKvO4At+g7+IJbV/OG2D7+c8 zG2srbLbbbZr01BbFBJqJdG1E3Wuwjg0kvFOLz0lrcFObDiEK+W1+Ts5u8+u9REU tHq1K1He7s26D9SDRG2kMdcZRJsLHM8D09aGkjq+39qCGd2+5felrBgSYpBGLecm C9Mw3kBl/Rix2RsK7RqmSqMFJfWmYftqc+7c7VPmCiv07uytyzDhA1GSJZDJhshP dhIhTrcdDHeIL/YeUOa3ObqoNeauNS3lZA9vyWz/62XAo4kx4kS23mWRheunkKxa EfAPRiHAoCG/20KqtL+A5/smYn0rcuxHJh1owPATc2Gvhud0YCIMoKo/s8hy2TWy gxvoIKI8YEgcv+zsSsAQ0JNy+m+G8ybh5zYZdvJaBJCxA+jTDwACSlmxAXxaSFQ+ DKZgg+imRRxAiBpv3WQdn2EzHlfQVy0U1Vv6Z+Q3WifkftyWfDcfB6Qk8LnaK3My XRy6jcftwMy9vSN5d/Xs =oPO5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Finding the Apache httpd IP address when AJP is used
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 4/30/15 5:13 AM, André Warnier wrote: Paul Klinkenberg wrote: Hi Christopher, Thanks for taking the time to respond; again much appreciated. Your point, and André's, is understood. Security should not be done based on incoming IP address. With this current project, we off course want to deliver software which is secure by default. Now, if someone would install Tomcat, then add the mod_cfml valve, and then doesn't lock port 8080 or 8009, the server would become vulnerable in the same way as if the /host-manager would not have password-protection. Currently, I am discussing with the main mod_cfml developers Jordan Michaels and Bilal Soylu how to implement security, since I now won't be implementing IP restriction. We'll probably go with using the secret configuration parameter for ajp like you suggested. Or maybe using a shared secret key between the frontend server and the Tomcat valve. In this last case, we would also have tackled security when remote attackers try to contact Tomcat on http-8080 directly, instead of using the ajp connector. I never knew the remote_addr could not be trusted, but I believe you at once when you say so. I thought it was taken from the actual socket connection. With the exception of ajp by the way, where it is programmatically changed to reflect the remote client while handling the http call. Out of curiosity, could you shed some light as to why the remote_addr is not to be trusted in a regular http request? Thanks again for your time and effort! Kind regards, Paul Klinkenberg On Tomcat, you can set the AJP Connector to only listen on the local IP address of the Tomcat server host. That means that only local LAN clients (including the httpd front-end, presumably) can connect to that Connector. So this already stops any external client (be it workstation or server) from even connecting to Tomcat using AJP. It also, presumably, insures that only your internal httpd front-ends can potentially connect to Tomcat via AJP. Not quite. You can bind to localhost, which only allows local connections. Or you can bind to * (all interfaces), which allows connections from anywhere. Or, you can bind to a specific interface (IP address), which also allows connections from anywhere. There is no interface to which you can bind that means only the local network, unless if course there is some other factor at work; such as an interface that is only connected to a local network. Now if you do not even trust your internal servers/clients, /then/ you need additional measures. But in such a case, whether you use a secret which the front-end must provide, or whether you use an additional header or Jk variable, is only a choice; but any of those requires some setup on the front-ends. +1 The same is for the other Connectors, like HTTP/HTTPS. If you do not want people to connect through these, disable them or have them also only listen on a local IP address. +1 The best way to protect against unauthorized access is to require authentication in some way that doesn't rely on some shaky and sloppy checking, like IP address. At some point, you have to trust your own web servers. If you don't trust your own web servers, it means you are expecting MitM attacks. Why not lock-down the connections between your web servers and your application servers and then not have to distrust incoming connections just in case they aren't coming from your web servers? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVQjgBAAoJEBzwKT+lPKRYKEIP/1fAJwB2F99YVcgDbLPo9zky aDRkX0Rvv73vVxJdWoOJsM1FsgGXBaPg83ZC383Ma9iKpI0E4+iLbSc3WNembMIr PgV+6yG7BYV0p2v51OXOfzFNp3fDml6gc9RLEiQ+r8k5Dj7MscCHnKZzwaghxRyf HBlSPy5k+TMrQsPEAIzx6mrM2r8VNVZjrisLXkatoviDGQG/9ji5q4OG6XVUv5pe fSkWTpH04MZsEG/bRIqak1as0jQnjHckw+XH2aamApWRsIuH2HTV685BqSVOp3ZV Cg1v0KXavJOjspWVPZpngDmTRaB4kvDt8pC2bbMUDxocZgw+SG/AwVY6IAvBpuPR 4oVB/vBGrY546lvjXxOvcr6RdNfs/+1pK6OFbaKcI5m4UxHVP1k8cRLCjRlcIKKX MRWYraCwfx9CWd6t97Ax1FXge0fMgXPWobcgaGTRT7IKm0pSDAXbOvzwPPUxWFOP aQ+nOIAp7He7kKsUEU/0DooV2Vzf+FVTNwW8z1rJMdPWd716OWS8ASUJi7yLVnOI rH/O6TQ9gAhfUaAGY0nRtpAtPCCI05eUxWe91G+IFKIAvZ4O30Mi1AouwNo08CjZ EBjpm7h67m5lkHQb/sVjCrMKcg70OnKEvjYbivgubf12HBrP89v1nTU/NE1fffD8 TuNP/MKIFBs6MzyrMh9H =EBju -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Exception in Tomcat7 when closing stream, server crashes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Osman, On 4/30/15 10:07 AM, Osman Ullah | Ntrepid Corp wrote: Just an update. We have been doing some testing and we might not be seeing Tomcat actually go down with 7.0.61. The errors are still occurring but it is possible it may not be crashing. We were seeing the crash with 7.0.56. I’ll post an update once have done some more thorough testing. Lots of little things are being cleaned-up in and around the connectors as well as tcnative lately. Using the latest Tomcat will improve the stability of tcnative, because if the Java code has been mis-tracking the state of the connection, the native code can sometimes fall-over. I've tried to prevent actual crashes as much as possible, but the result in those cases is that the connection is totally trashed. I'm not sure if Tomcat is recycling those trashed connections, but every release improves the situation. It would be even better if you could move up to Tomcat 8. Lots more refactoring of the connectors has taken place there and so all connectors are more stable. I'm excited about the upcoming Tomcat 9 because the connector code has been nearly unified. This ought to make all of the connectors rock-solid . - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVQjlgAAoJEBzwKT+lPKRY7QQP/3icbNyKKRTpFDiIUT4KEqOe tuetGpc27If1yHuoXAWcmeLmVpXcuM2i4zk0rMZwIhUJT0c5YaNn7tEBft4atCUv 7+cPBAyXb55rTtLra9DUoEl8PU3JXPWTVzWFHLw94MxubA3mHdV2cVal36USzZXS QAbeBADt8szgZ5u2VBMQSqCknVYjR+hUAzqPgrirPx0LlEYR+yFkgtjOfJSTTuL9 XwodnGvzfmzHAqZXW7htkwV7koXZF8018dQ41+sW/vdYq1la05hPG5idSvcYINwY AySJ/ydrv91EdVOOhUR2m3SZMczGulGb18gsjtrgJzx2xVW/seKoCaRIUYpVIhuE 4KM53tM9qkR4QG6Un+NRrKyU+AkEpxKy2cvLatTln27KPel1+VM+CWKeLJ/U9tBo 6yJEygOoy/pWlwiBHbEy9kmF4v9FOY6SUo4u4T91KFDL1pXnAI5W0gAVKG7V4nVC 2FYbhNAhHw+68KH6dn2IU0Co24O+5OTt6Vyu9tzMqdSzEFchfQuLTrNBk3DnueWw BsjrOJ3bq3ZB1AgaKC1WVqEKY7dGyV1zGUjRucTr4dqZ9rzyBmqudFPXP/hvRNYp 4yuxtBxt8jd2ol/0ukzOfb7c5E0ABoGnykQxbUXm0q9ujdEU3a6GSSR03iLd6qrU pq6Mk5YvMIuI3fJufZMt =vDEq -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7 in chroot environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Andrea, On 4/29/15 5:37 PM, Andrea Freire wrote: Just a little question the apt-get command when you execute inside the chroot doesn't install all the dependencies. Date: Wed, 29 Apr 2015 16:36:41 -0400 From: ch...@christopherschultz.net To: users@tomcat.apache.org Subject: Re: FW: tomcat7 in chroot environment Andrea, On 4/29/15 4:14 PM, Andrea Freire wrote: excuse me I have a little problem with the tomcat7 installation. The tomcat7 install with apt-get for a opengeosuite-server installer in a chroot with ubuntu environment, the problem is when I want to start the service in the chroot console it throws me a message: * tomcat7 is not installed I change the /var/lib/tomcat7 an /usr/share/tomcat7 folders owner to tomcat7 because there was with root as owner in the folders in the chroot environment in the past this resolve the problem in a tipical installing and change the CATALINA_BASE an CATALINA_HOME in the start script in the /etc/init.d/tomcat7 with the folders in the chroot environment. In the beginning the message when I execute the command service tomcat7 start doesn't throws me nothing, all was normal but I can´t see the web page or the service running from another machine. I see that the link to the folder /var/lib/tomcat7 in the chroot environment doesn´t go to a file inside the chroot I change that to the ubication inside the chroot then began with the problem. What you have to understand about chroot is that 100% of what you need to launch your process needs to be available *inside* the chroot'd environment. So, if you need to chroot to /var/tomcat/chroot, then you are going to need a directory at /var/tomcat/chroot/var/lib/tomcat7 containing whatever files you expected to be there. Have you had Tomcat working in a chroot'd environment in the past? I've had a nightmare of a time trying to get a JVM to launch within a chroot'd environment because it needs to many support libraries, etc. available just to start. Once the JVM can launch within the chroot'd environment, getting Tomcat to work should be trivial: just move everything Tomcat needs into the chroot root-dir (likely a subdirectory of this, actually) and you should be fine. As for launching Tomcat within the chroot'd environment from a service script, your service script needs to execute the chroot command and then give a command to run once the chroot() system call has completed. Presumably, that command will be /path/to/tomcat/bin/catalina.sh start. The /path/to/tomcat should be relative to the chroot's root, and both CATALINA_BASE and CATALINA_HOME should also be relative to the chroot's root directory. Hope that helps, -chris Is that a question? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVQjaZAAoJEBzwKT+lPKRYtpUQAK4s1LFg4yUNEMW2iInFtMLh r8dzpulVZ0ksEKaSWnnUTJFecGpED0F2ZepnCFOJ7z3YPu0u7wXw6Xpr0B1B57Bg L1d2C44s4smrn5Cj6JCYEV0QGPaTQh7+0W79InQGzwc54bPhIY+BR5QWfzmyr9+u ajsI7l2l6eXv5rcspik36RAJ3qwssU6NPQHI2dGgSxZWMcEcgWRDVNENyT8Pk35Z cJ0fQ0PG8Mvbvnp+qXXxoKvEeSSF+NPPDqeZR6/yqRAD2CV2ghlDsd3nrpUTdTay gIrkbd1Jfn/PBkM/3EKyl9N01VsZMNTAPSXQuaYuGkZbzBZbrY0xoBqJf3Jm/42E gHx/WO6zYAiEQvJu895ci/ubt87V2S1jcHapVhTZpEl4NGwkcHQuzh1WLaev5+BE ClgUBzji7AwAeCkWwvemcEk99DqmJLeIW3bTPksyE8aXUI0x8ifqaRLcG5MUH185 mfGQdh7qP6AwFt+MxReDXxKit40DQKzBtmR8FaBZBnIf6rsgVMgaf9fces7ZBfy9 543KUxrmgB+EwYMY1d++t/33f33BMLuYfcLYvjlzOqveCq9o5lD5K2EJndIShIhm o3a2rxvLW88hWZxyzZfKM1FuNBgd4lTOcnipu4IYAfyaQzSlze+L/+7wZwNL/zA0 uGtjrNDA9aWKMBCLUP57 =CRer -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Finding the Apache httpd IP address when AJP is used
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Paul, On 4/30/15 3:24 AM, Paul Klinkenberg wrote: I never knew the remote_addr could not be trusted, but I believe you at once when you say so. I thought it was taken from the actual socket connection. With the exception of ajp by the way, where it is programmatically changed to reflect the remote client while handling the http call. Out of curiosity, could you shed some light as to why the remote_addr is not to be trusted in a regular http request? The client can spoof the source IP in the packet headers. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVQjcQAAoJEBzwKT+lPKRY4HEP/30Lih3AbOBVh1fujyoB0fZd tne7zc3bJnrhtwl3f5Je1YlLR+ij545HYlcRTeM6UFlh2k8N7rFTJIPdLlnbt4jC 62FPkmBYZQqtccgv/AP/E+jI75kstAW47LvL4UEOS0p/UwgW2phEN7Ko0SKvaHDk YWj5/LrtCBfsZFLJeGqgcbU2c38BFdBZGS1zWgGgCuz53kH8y1LPKj7zgs0LuDOn IHEFWVcXbUbHqcAS6Cfb6UV4kI1JiSTmtoufaqpcBOQtRG4lVMcrsK3660W8FMXC DercNpofhYIX+E5B19FI1QlYl1dTd4Wz17QTMqsiK1T9qNG5JczYIHi3VX6KGwT9 oj5LO7K0v6E653gQBo+pcIJO6H44xOdg1J/U8rNuyTkfU2Vr+fMOA321kEchRYRj Zb8J7DTtNuHAW5ncwH4YTqvEnbg2p9ZoF9tCB9330u3wdWsVCj/62WX6XT908ElD hs2Z73qhdbm7REu8KPtk9WQkylNhptA6Uxe8ZPBD7jfxGPAR7KvpwwXPV2irhG/e 7Iq8SbmMK9zpI4W6oodjiv+olQmj8qo5tuSrpTbW264GSrioKVZ9jkclxfkzrtuf utdotevKsCAOXQYzhtHcU6NkxUgvZZ76YOBmKBineEmb1ieXQzeQ0PgJdOHXVqpe AYfiVawe60dkGrsKdr5R =9bH5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Finding the Apache httpd IP address when AJP is used
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Paul, On 4/29/15 10:18 PM, l...@bsoft.com.cn wrote: p.s. I asked this question, in other wording, on SackOverflow.com http://sackoverflow.com/ as well. I hope I have better luck here ;-) http://stackoverflow.com/questions/29858030/where-can-i-find-the-apach e-httpd-server-ip-from-within-a-tomcat-valve-when-ajp http://stackoverflow.com/questions/29858030/where-can-i-find-the-apac he-httpd-server-ip-from-within-a-tomcat-valve-when-ajp It's more clear from this post that you just want to make sure that the HTTP (or AJP) request is coming from localhost. If that's all you want, then change the Connector configuration so that it's only listening on localhost, like this: Connector address=127.0.0.1 ... / This will prevent any incoming connections from the outside world. Does that solve your problem? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVQjiaAAoJEBzwKT+lPKRYyD0QAIS4KmX2osUNxLAd/taX9NP6 cHNaJnMgekgVNpvh5QpuGRO2e1ivMmheyBSo3lFtnK8kF++VIBZBpDqAZO/PUX1H ubSo62ip6QCSSoonVKeWzrSFvDCN8xAb9R4FNRu+GbIV+ubiGfghYct+J0R1HXq0 1Ncm4SOpXjsYoOZDGK/AwMfoJDoN0QemvSuKp7ftASD0SCV4EOhZya6JCxLKMQte dCtv+rfd0Q/qjVizDGdmCT3qqLHUMQ5eLy6dhveHny9vU5KT8ORfOrTZ6REmxnHe pkhWFIv6hUPeSZw+kW4SlVQhBweet2bDfnso8zDkp65un9YRbUW+edSMTi8VD1aG Z/AwjTXWjQF83+g6SY7asV6bcpGOFbYeRIVWB8NI14Z1rLLlicDPjJaD9EHYCM0q jaoPNXprcQGrjFhcSCHBXjMdp6trK9es83+E8PeFJF9i5UTnWii2+k4GL05/MSxx pysLFMiV4V14BOwR8yq7iWcMMzNxf7d6bCyYna4oHhsGfiqlJEKgg3AFyTPc+Ebb +HOEqm+MkPFtM0TIsXhQBDvPu13SR0yTB894J/ns1PHLE7XlmBtgZ7+lPuRFINbQ 0eEWPKPoQGttkaibLRT7u3alLRPBUG4gqWUl0Ux16aOBdyJpTLoJsMm+cLYNgj0t cuPcHfwY7LAVKjaQTKrU =AsyJ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Finding the Apache httpd IP address when AJP is used
Hi André, Paul Klinkenberg wrote: Hi Christopher, Thanks for taking the time to respond; again much appreciated. Your point, and André's, is understood. Security should not be done based on incoming IP address. With this current project, we off course want to deliver software which is secure by default. Now, if someone would install Tomcat, then add the mod_cfml valve, and then doesn't lock port 8080 or 8009, the server would become vulnerable in the same way as if the /host-manager would not have password-protection. Currently, I am discussing with the main mod_cfml developers Jordan Michaels and Bilal Soylu how to implement security, since I now won't be implementing IP restriction. We'll probably go with using the secret configuration parameter for ajp like you suggested. Or maybe using a shared secret key between the frontend server and the Tomcat valve. In this last case, we would also have tackled security when remote attackers try to contact Tomcat on http-8080 directly, instead of using the ajp connector. I never knew the remote_addr could not be trusted, but I believe you at once when you say so. I thought it was taken from the actual socket connection. With the exception of ajp by the way, where it is programmatically changed to reflect the remote client while handling the http call. Out of curiosity, could you shed some light as to why the remote_addr is not to be trusted in a regular http request? Thanks again for your time and effort! Kind regards, Paul Klinkenberg On Tomcat, you can set the AJP Connector to only listen on the local IP address of the Tomcat server host. That means that only local LAN clients (including the httpd front-end, presumably) can connect to that Connector. So this already stops any external client (be it workstation or server) from even connecting to Tomcat using AJP. It also, presumably, insures that only your internal httpd front-ends can potentially connect to Tomcat via AJP. Now if you do not even trust your internal servers/clients, /then/ you need additional measures. But in such a case, whether you use a secret which the front-end must provide, or whether you use an additional header or Jk variable, is only a choice; but any of those requires some setup on the front-ends. The same is for the other Connectors, like HTTP/HTTPS. If you do not want people to connect through these, disable them or have them also only listen on a local IP address. Thanks for these tips. I see there are quite a few options to secure the AJP connector, which is great. For the project I am currently working on, I have to take into consideration that the user might already have Tomcat installed, and then probably with the default configuration. That would mean the AJP connector is available, and http connector as well. When someone now wants to add the mod_cfml valve to their setup, I will warn them in the install/config notes to lock down their tomcat server, if they haven't done so already. Next to this, I would like to be able to make the valve secure by default, without having to rely on external settings. For this secure by default, a required shared secret key seems like a solution to me. Remote users accessing either the http connector or ajp connector (only possible if the server is not firewalled), would need to have that key in order to get the valve to create a new context. I _do_ trust the internal servers/clients, I just want to make sure that if a mod_cfml user was too lame to secure it's server, then mod_cfml isn't the weakest link to be able to hack the server. I hope that makes sense? Kind regards, Paul Klinkenberg Op 29 apr. 2015, om 17:48 heeft Christopher Schultz ch...@christopherschultz.net het volgende geschreven: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Paul, On 4/29/15 11:17 AM, Paul Klinkenberg wrote: The reason I want to add the IP restriction in the valve, is to make 100% sure that the request (for creating a new Tomcat context) is indeed coming from the frontend webserver. I think there are better ways to do this. Among them: 1. Firewall rule that only allows access to the AJP port from a certain IP address/range. 2. Use of the secret configuration parameter for mod_jk/AJP connector In production, we tunnel AJP from our web servers to our application servers using stunnel, and stunnel connections are only allowed from the range of IPs used by our web servers. Then, we actually have the AJP connector listen on ::1 so nobody from the outside can connect to us, except through such a tunnel. This valve is a setup not just for me, where I could tweak server settings and such, but for anyone who uses the mod_cfml connector. It is installed by default by the Railo/Lucee installers (getrailo.org http://getrailo.org/ / lucee.org http://lucee.org/) It seems a little fragile, because it requires configuration beyond what an
Re: unable to install tomcat7 on windows 2012 --- getting access denied
On 4/30/2015 9:49 AM, Jeffrey Janner wrote: -Original Message- From: George Sexton [mailto:geor...@mhsoftware.com] Sent: Thursday, April 30, 2015 10:44 AM To: users@tomcat.apache.org Subject: Re: unable to install tomcat7 on windows 2012 --- getting access denied On 4/30/2015 9:40 AM, Jeffrey Janner wrote: Turn off UAC, run the install, turn back on UAC. Or, run the command prompt as an administrator and then run the script. He said he'd already tried that. I've had the UAC decide I'm not an Admin even when my user ID and/or group was a member of the Local Administrator's group on the machine. I've even seen it deny admin rights to commands run from and Admin console session - depending on the command. The really confusing and annoying thing is this. If you login as Administrator and run a command prompt, you don't get elevated privileges in the shell. You actually have to right click on the command prompt and choose run as Administrator to get elevated privileges. It's retarded, but it's Windows. -- George Sexton *MH Software, Inc.* Voice: 303 438 9585 http://www.mhsoftware.com
Re: Finding the Apache httpd IP address when AJP is used
Hi André, Paul Klinkenberg wrote: Hi André, Paul Klinkenberg wrote: Hi Christopher, Thanks for taking the time to respond; again much appreciated. Your point, and André's, is understood. Security should not be done based on incoming IP address. With this current project, we off course want to deliver software which is secure by default. Now, if someone would install Tomcat, then add the mod_cfml valve, and then doesn't lock port 8080 or 8009, the server would become vulnerable in the same way as if the /host-manager would not have password-protection. Currently, I am discussing with the main mod_cfml developers Jordan Michaels and Bilal Soylu how to implement security, since I now won't be implementing IP restriction. We'll probably go with using the secret configuration parameter for ajp like you suggested. Or maybe using a shared secret key between the frontend server and the Tomcat valve. In this last case, we would also have tackled security when remote attackers try to contact Tomcat on http-8080 directly, instead of using the ajp connector. I never knew the remote_addr could not be trusted, but I believe you at once when you say so. I thought it was taken from the actual socket connection. With the exception of ajp by the way, where it is programmatically changed to reflect the remote client while handling the http call. Out of curiosity, could you shed some light as to why the remote_addr is not to be trusted in a regular http request? Thanks again for your time and effort! Kind regards, Paul Klinkenberg On Tomcat, you can set the AJP Connector to only listen on the local IP address of the Tomcat server host. That means that only local LAN clients (including the httpd front-end, presumably) can connect to that Connector. So this already stops any external client (be it workstation or server) from even connecting to Tomcat using AJP. It also, presumably, insures that only your internal httpd front-ends can potentially connect to Tomcat via AJP. Now if you do not even trust your internal servers/clients, /then/ you need additional measures. But in such a case, whether you use a secret which the front-end must provide, or whether you use an additional header or Jk variable, is only a choice; but any of those requires some setup on the front-ends. The same is for the other Connectors, like HTTP/HTTPS. If you do not want people to connect through these, disable them or have them also only listen on a local IP address. Thanks for these tips. I see there are quite a few options to secure the AJP connector, which is great. For the project I am currently working on, I have to take into consideration that the user might already have Tomcat installed, and then probably with the default configuration. That would mean the AJP connector is available, and http connector as well. When someone now wants to add the mod_cfml valve to their setup, I will warn them in the install/config notes to lock down their tomcat server, if they haven't done so already. Next to this, I would like to be able to make the valve secure by default, without having to rely on external settings. For this secure by default, a required shared secret key seems like a solution to me. Note : to check. I am not sure if the HTTP/HTTPS Connectors provide this shared secret thing. This may well be an AJP Connector feature only. Remote users accessing either the http connector or ajp connector (only possible if the server is not firewalled), would need to have that key in order to get the valve to create a new context. I _do_ trust the internal servers/clients, I just want to make sure that if a mod_cfml user was too lame to secure it's server, then mod_cfml isn't the weakest link to be able to hack the server. I hope that makes sense? Ok, so at this point, you only want to know, by intellectual curiosity, *how you could* theoretically, in your Valve, obtain the IP address and port of the front-end proxy server who is forwarding the original client request to your Tomcat. Oof, that was hard to write, and I hope it is correct. Actually, Christopher already provided the answer to that, in a previous post : The only way to check the caller would be to get ahold of the Socket that Tomcat is using to communicate. That's not easily done, since Tomcat wants to protect its sockets from code messing-around with the state of those Sockets. That's a clue, but not a very helpful one for you, is it ? I believe that the main issue here is that there is no such standard functionality dictated by the Servlet Specification, so there is no obligation for any Servlet Engine to provide this, and apparently thus Tomcat does not provide a way to obtain this information easily, because it doesn't have to. And according to Christopher, there may even be a deliberate attempt from the Tomcat code to prevent one
Re: Finding the Apache httpd IP address when AJP is used
Paul Klinkenberg wrote: Hi André, Paul Klinkenberg wrote: Hi Christopher, Thanks for taking the time to respond; again much appreciated. Your point, and André's, is understood. Security should not be done based on incoming IP address. With this current project, we off course want to deliver software which is secure by default. Now, if someone would install Tomcat, then add the mod_cfml valve, and then doesn't lock port 8080 or 8009, the server would become vulnerable in the same way as if the /host-manager would not have password-protection. Currently, I am discussing with the main mod_cfml developers Jordan Michaels and Bilal Soylu how to implement security, since I now won't be implementing IP restriction. We'll probably go with using the secret configuration parameter for ajp like you suggested. Or maybe using a shared secret key between the frontend server and the Tomcat valve. In this last case, we would also have tackled security when remote attackers try to contact Tomcat on http-8080 directly, instead of using the ajp connector. I never knew the remote_addr could not be trusted, but I believe you at once when you say so. I thought it was taken from the actual socket connection. With the exception of ajp by the way, where it is programmatically changed to reflect the remote client while handling the http call. Out of curiosity, could you shed some light as to why the remote_addr is not to be trusted in a regular http request? Thanks again for your time and effort! Kind regards, Paul Klinkenberg On Tomcat, you can set the AJP Connector to only listen on the local IP address of the Tomcat server host. That means that only local LAN clients (including the httpd front-end, presumably) can connect to that Connector. So this already stops any external client (be it workstation or server) from even connecting to Tomcat using AJP. It also, presumably, insures that only your internal httpd front-ends can potentially connect to Tomcat via AJP. Now if you do not even trust your internal servers/clients, /then/ you need additional measures. But in such a case, whether you use a secret which the front-end must provide, or whether you use an additional header or Jk variable, is only a choice; but any of those requires some setup on the front-ends. The same is for the other Connectors, like HTTP/HTTPS. If you do not want people to connect through these, disable them or have them also only listen on a local IP address. Thanks for these tips. I see there are quite a few options to secure the AJP connector, which is great. For the project I am currently working on, I have to take into consideration that the user might already have Tomcat installed, and then probably with the default configuration. That would mean the AJP connector is available, and http connector as well. When someone now wants to add the mod_cfml valve to their setup, I will warn them in the install/config notes to lock down their tomcat server, if they haven't done so already. Next to this, I would like to be able to make the valve secure by default, without having to rely on external settings. For this secure by default, a required shared secret key seems like a solution to me. Note : to check. I am not sure if the HTTP/HTTPS Connectors provide this shared secret thing. This may well be an AJP Connector feature only. Remote users accessing either the http connector or ajp connector (only possible if the server is not firewalled), would need to have that key in order to get the valve to create a new context. I _do_ trust the internal servers/clients, I just want to make sure that if a mod_cfml user was too lame to secure it's server, then mod_cfml isn't the weakest link to be able to hack the server. I hope that makes sense? Ok, so at this point, you only want to know, by intellectual curiosity, *how you could* theoretically, in your Valve, obtain the IP address and port of the front-end proxy server who is forwarding the original client request to your Tomcat. Oof, that was hard to write, and I hope it is correct. Actually, Christopher already provided the answer to that, in a previous post : The only way to check the caller would be to get ahold of the Socket that Tomcat is using to communicate. That's not easily done, since Tomcat wants to protect its sockets from code messing-around with the state of those Sockets. That's a clue, but not a very helpful one for you, is it ? I believe that the main issue here is that there is no such standard functionality dictated by the Servlet Specification, so there is no obligation for any Servlet Engine to provide this, and apparently thus Tomcat does not provide a way to obtain this information easily, because it doesn't have to. And according to Christopher, there may even be a deliberate attempt from the Tomcat code to prevent one being able to do such things easily, because it could potentially mess up things pretty badly if one
Re: [OT] Finding the Apache httpd IP address when AJP is used
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Paul, On 4/30/15 3:24 AM, Paul Klinkenberg wrote: I never knew the remote_addr could not be trusted, but I believe you at once when you say so. I thought it was taken from the actual socket connection. With the exception of ajp by the way, where it is programmatically changed to reflect the remote client while handling the http call. Out of curiosity, could you shed some light as to why the remote_addr is not to be trusted in a regular http request? The client can spoof the source IP in the packet headers. This is not on-topic, but since the point has been raised, and since there are many smart people on this list.. I am probably not very clever in a hacking kind of way, but I have never been able to figure out how a client could make use of this to actually achieve something with TCP. Setting up a TCP connection requires a couple of packet exchanges *back and forth*. So, the client can indeed send a first SYN packet to a server, with a spoofed origin IP address. But then the server would return the ACK packet to that spoofed IP address, which is presumably not the real client's one, wouldn't it ? What good would that be to the malevolent client ? Unless the point is only to flood a server's TCP stack with connection requests which never can get completed.. If anyone has a clue as to how this can be really exploited, I'm eager to learn. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Trouble separating catalina_base and catalina_home in TC 8
I'm having trouble getting the default webapps to start under TC8 when I separate catalina_base and catalina_home. It must be something stupid I'm missing, but I can't think of any place else to check. This is a windows server 2012 R2 server, with JRE 7u75, JRE 8u45, TC 7.0.57 and TC 8.0.21 all installed as 32-bit under Program Files (x86). TC is as a windows service in both cases, and they were installed using the windows service installer .exe. TC7 is set up to use JRE 7, and TC 8 to use JRE8. Everything runs fine under TC7, but I appear to be having some interference when I try to run apps under TC8, not from catalina_home. All the following comments are running TC8. Everything works fine when I run the manager app from its original (catalina_home) location, but when I try to move it to catalina_base, it fails, apparently trying to start TC 7. These are the first 30 lines from the stderr log. There are more errors later on in the log, but I believe they are cascading from the initial problems. Specifically, note that it shows CATALINA_HOME as the correct TC8 location, but it says it's starting 7.0.57 (line2). 2015-04-30 18:22:04 Commons Daemon procrun stderr initialized 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version: Apache Tomcat/7.0.57 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built: Nov 3 2014 08:39:16 UTC 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server number: 7.0.57.0 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: Windows Server 2008 R2 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version: 6.1 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture: x86 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JAVA_HOME: C:\Program Files (x86)\Java\jre8 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: 1.8.0_45-b14 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: Oracle Corporation 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: F:\tomcat8_clients 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: C:\Program Files (x86)\Apache Software Foundation\Tomcat 8.0 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.home=C:\Program Files (x86)\Apache Software Foundation\Tomcat 8.0 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.base=f:\tomcat8_clients 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.endorsed.dirs=C:\Program Files (x86)\Apache Software Foundation\Tomcat 8.0\endorsed 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=f:\tomcat8_clients\temp 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=f:\tomcat8_clients\conf\logging.properties 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -DWebSira.configFileName=F:\tomcat8_clients\PelicanWebSIRA.properties 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: exit 30-Apr-2015 18:22:06.107 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Xms128m 30-Apr-2015 18:22:06.107 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Xmx256m 30-Apr-2015 18:22:06.107 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:\Program Files (x86)\Apache Software Foundation\Tomcat 8.0\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\SQL Anywhere 12\bin64;C:\Program Files\SQL Anywhere 12\bin32;;. 30-Apr-2015 18:22:06.357 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing
Re: Trouble separating catalina_base and catalina_home in TC 8
2015-04-30 21:49 GMT+03:00 David kerber dcker...@verizon.net: I'm having trouble getting the default webapps to start under TC8 when I separate catalina_base and catalina_home. It must be something stupid I'm missing, but I can't think of any place else to check. This is a windows server 2012 R2 server, with JRE 7u75, JRE 8u45, TC 7.0.57 and TC 8.0.21 all installed as 32-bit under Program Files (x86). TC is as a windows service in both cases, and they were installed using the windows service installer .exe. TC7 is set up to use JRE 7, and TC 8 to use JRE8. Everything runs fine under TC7, but I appear to be having some interference when I try to run apps under TC8, not from catalina_home. All the following comments are running TC8. Everything works fine when I run the manager app from its original (catalina_home) location, but when I try to move it to catalina_base, it fails, apparently trying to start TC 7. These are the first 30 lines from the stderr log. There are more errors later on in the log, but I believe they are cascading from the initial problems. Specifically, note that it shows CATALINA_HOME as the correct TC8 location, but it says it's starting 7.0.57 (line2). 2015-04-30 18:22:04 Commons Daemon procrun stderr initialized 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version: Apache Tomcat/7.0.57 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built: Nov 3 2014 08:39:16 UTC 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server number: 7.0.57.0 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: Windows Server 2008 R2 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version: 6.1 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture: x86 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JAVA_HOME: C:\Program Files (x86)\Java\jre8 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: 1.8.0_45-b14 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: Oracle Corporation 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: F:\tomcat8_clients 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: C:\Program Files (x86)\Apache Software Foundation\Tomcat 8.0 1) It is rather possible to install Tomcat 7 into directory named Tomcat 8.0. Check what jars are actually there. The version number comes from a file in catalina.jar named org/apache/catalina/util/ServerInfo.properties 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.home=C:\Program Files (x86)\Apache Software Foundation\Tomcat 8.0 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.base=f:\tomcat8_clients 2) OK, catalina.home and catalina.base system properties are present. 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.endorsed.dirs=C:\Program Files (x86)\Apache Software Foundation\Tomcat 8.0\endorsed 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=f:\tomcat8_clients\temp 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=f:\tomcat8_clients\conf\logging.properties 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -DWebSira.configFileName=F:\tomcat8_clients\PelicanWebSIRA.properties 30-Apr-2015 18:22:06.092 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: exit 30-Apr-2015 18:22:06.107 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Xms128m 30-Apr-2015 18:22:06.107 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Xmx256m 30-Apr-2015 18:22:06.107 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:\Program Files (x86)\Apache Software Foundation\Tomcat
Re: Debugging Tomcat Running in Vagrant using Port Forwarding
2015-05-01 3:29 GMT+03:00 David Landis dlan...@gmail.com: On Thu, Apr 30, 2015 at 5:24 PM, Konstantin Kolinko knst.koli...@gmail.com wrote: Have you started Tomcat in debug mode? E.g. ./catalina.sh jpda start See JPDA_ADDRESS option in catalina.sh source code. Hi Konstantin. Yes I have. Like I noted in the original question Tomcat correctly outputs on startup: Listening for transport dt_socket at address: 8000 OK. P.S. It is not a firewall issue. Note that you have 2 firewalls, one on your own machine (to allow outgoing connections), another on the one running in virtual box (to allow incoming connections). Can you connect with a simple client, e.g. telnet? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Debugging Tomcat Running in Vagrant using Port Forwarding
On Thu, Apr 30, 2015 at 6:06 PM, Konstantin Kolinko knst.koli...@gmail.com wrote: Note that you have 2 firewalls, one on your own machine (to allow outgoing connections), another on the one running in virtual box (to allow incoming connections). Can you connect with a simple client, e.g. telnet? Yeah firewall is definitely off in the VM and I temporarily turned off the firewall in Windows as well. You mean `telnet localhost 8000` right? It seems to work, as in just hangs whereas telnet to another random port returns Connect Failed right away.
Re: Debugging Tomcat Running in Vagrant using Port Forwarding
On Thu, Apr 30, 2015 at 5:24 PM, Konstantin Kolinko knst.koli...@gmail.com wrote: Have you started Tomcat in debug mode? E.g. ./catalina.sh jpda start See JPDA_ADDRESS option in catalina.sh source code. Hi Konstantin. Yes I have. Like I noted in the original question Tomcat correctly outputs on startup: Listening for transport dt_socket at address: 8000
Re: Debugging Tomcat Running in Vagrant using Port Forwarding
2015-05-01 3:13 GMT+03:00 David Landis dlan...@gmail.com: On Thu, Apr 30, 2015 at 3:12 PM, David Marsh dmars...@outlook.com wrote: 8000 Is the HTTP port in development just in case you are using port 808433 Is similar for HTTPS22 Is SSH port Normally you define a free port in a user range say 9009, to be your debug port. Then you use a suitable java debugger to connect to that port. I've never used vagrant, but it sounds like you'd also need that debug port say 9009, to have port forwarding configured. Once port forwarding is configured the debug port 9009 should be accessible outside the VM. Hi David -- thanks for the response. Port 8000 is definitely the default debugging port for Tomcat though and is what I've always used before when debugging locally. I suspect there is some additional configuration I need to do in Tomcat in order to debug while it is running in a Vagrant box using port forwarding. Have you started Tomcat in debug mode? E.g. ./catalina.sh jpda start See JPDA_ADDRESS option in catalina.sh source code. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Debugging Tomcat Running in Vagrant using Port Forwarding
8000 Is the HTTP port in development just in case you are using port 808433 Is similar for HTTPS22 Is SSH port Normally you define a free port in a user range say 9009, to be your debug port. Then you use a suitable java debugger to connect to that port. I've never used vagrant, but it sounds like you'd also need that debug port say 9009, to have port forwarding configured. Once port forwarding is configured the debug port 9009 should be accessible outside the VM. Date: Thu, 30 Apr 2015 14:44:13 -0700 Subject: Debugging Tomcat Running in Vagrant using Port Forwarding From: dlan...@gmail.com To: users@tomcat.apache.org Hi, I was wondering if anyone here might have any idea about this issue I was having debugging my Tomcat app. I posted this question on Stack Overflow several days ago but didn't get any responses (and it said it was only viewed 15 times despite having the Java and Tomcat tags which is weird). Anyway, here is the question, thanks: I'm trying to attach my Eclipse debugger running on my Windows host to a Tomcat 8 server running in my local Vagrant box (Virtual Box) running CentOS 7. Here is the full error from the Eclipse logs: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:179) at java.io.DataInputStream.readFully(DataInputStream.java:189) at java.io.DataInputStream.readFully(DataInputStream.java:163) at org.eclipse.jdi.internal.connect.SocketTransportService.readHandshake(SocketTransportService.java:216) at org.eclipse.jdi.internal.connect.SocketTransportService.access$7(SocketTransportService.java:212) at org.eclipse.jdi.internal.connect.SocketTransportService$3.run(SocketTransportService.java:183) at java.lang.Thread.run(Thread.java:761) The output from `vagrant up` seems correct (port 8000 is the debugging port): == default: Preparing network interfaces based on configuration... default: Adapter 1: nat == default: Forwarding ports... default: 8000 = 8000 (adapter 1) default: 8443 = 8443 (adapter 1) default: 22 = (adapter 1) I can access my application (using https://localhost:8443/app) via a browser from my host without issue; connecting the debugger is the issue. The debugger is configured for a Remote Java Application with connection properties: Host: localhost Port: 8000 Starting Tomcat of course displays the correct: Listening for transport dt_socket at address: 8000 Based on the some other questions, the answer maybe have something to do with configuring Tomcat to run on 0.0.0.0 instead of the default. So I tried configuring the Connectors in Tomcat's server.xml with the line address=0.0.0.0 but the result was the same. Any other ideas about getting this to work? Also, assuming the answer is something to do with changing the address to 0.0.0.0, why would I need to do that to get the debugger to work if accessing the app via browser is already fine on localhost:8443? P.S. It is not a firewall issue.
Debugging Tomcat Running in Vagrant using Port Forwarding
Hi, I was wondering if anyone here might have any idea about this issue I was having debugging my Tomcat app. I posted this question on Stack Overflow several days ago but didn't get any responses (and it said it was only viewed 15 times despite having the Java and Tomcat tags which is weird). Anyway, here is the question, thanks: I'm trying to attach my Eclipse debugger running on my Windows host to a Tomcat 8 server running in my local Vagrant box (Virtual Box) running CentOS 7. Here is the full error from the Eclipse logs: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:179) at java.io.DataInputStream.readFully(DataInputStream.java:189) at java.io.DataInputStream.readFully(DataInputStream.java:163) at org.eclipse.jdi.internal.connect.SocketTransportService.readHandshake(SocketTransportService.java:216) at org.eclipse.jdi.internal.connect.SocketTransportService.access$7(SocketTransportService.java:212) at org.eclipse.jdi.internal.connect.SocketTransportService$3.run(SocketTransportService.java:183) at java.lang.Thread.run(Thread.java:761) The output from `vagrant up` seems correct (port 8000 is the debugging port): == default: Preparing network interfaces based on configuration... default: Adapter 1: nat == default: Forwarding ports... default: 8000 = 8000 (adapter 1) default: 8443 = 8443 (adapter 1) default: 22 = (adapter 1) I can access my application (using https://localhost:8443/app) via a browser from my host without issue; connecting the debugger is the issue. The debugger is configured for a Remote Java Application with connection properties: Host: localhost Port: 8000 Starting Tomcat of course displays the correct: Listening for transport dt_socket at address: 8000 Based on the some other questions, the answer maybe have something to do with configuring Tomcat to run on 0.0.0.0 instead of the default. So I tried configuring the Connectors in Tomcat's server.xml with the line address=0.0.0.0 but the result was the same. Any other ideas about getting this to work? Also, assuming the answer is something to do with changing the address to 0.0.0.0, why would I need to do that to get the debugger to work if accessing the app via browser is already fine on localhost:8443? P.S. It is not a firewall issue.
Re: Finding the Apache httpd IP address when AJP is used
Paul Klinkenberg wrote: Hi André, Paul Klinkenberg wrote: Hi André, Paul Klinkenberg wrote: Hi Christopher, Thanks for taking the time to respond; again much appreciated. Your point, and André's, is understood. Security should not be done based on incoming IP address. With this current project, we off course want to deliver software which is secure by default. Now, if someone would install Tomcat, then add the mod_cfml valve, and then doesn't lock port 8080 or 8009, the server would become vulnerable in the same way as if the /host-manager would not have password-protection. Currently, I am discussing with the main mod_cfml developers Jordan Michaels and Bilal Soylu how to implement security, since I now won't be implementing IP restriction. We'll probably go with using the secret configuration parameter for ajp like you suggested. Or maybe using a shared secret key between the frontend server and the Tomcat valve. In this last case, we would also have tackled security when remote attackers try to contact Tomcat on http-8080 directly, instead of using the ajp connector. I never knew the remote_addr could not be trusted, but I believe you at once when you say so. I thought it was taken from the actual socket connection. With the exception of ajp by the way, where it is programmatically changed to reflect the remote client while handling the http call. Out of curiosity, could you shed some light as to why the remote_addr is not to be trusted in a regular http request? Thanks again for your time and effort! Kind regards, Paul Klinkenberg On Tomcat, you can set the AJP Connector to only listen on the local IP address of the Tomcat server host. That means that only local LAN clients (including the httpd front-end, presumably) can connect to that Connector. So this already stops any external client (be it workstation or server) from even connecting to Tomcat using AJP. It also, presumably, insures that only your internal httpd front-ends can potentially connect to Tomcat via AJP. Now if you do not even trust your internal servers/clients, /then/ you need additional measures. But in such a case, whether you use a secret which the front-end must provide, or whether you use an additional header or Jk variable, is only a choice; but any of those requires some setup on the front-ends. The same is for the other Connectors, like HTTP/HTTPS. If you do not want people to connect through these, disable them or have them also only listen on a local IP address. Thanks for these tips. I see there are quite a few options to secure the AJP connector, which is great. For the project I am currently working on, I have to take into consideration that the user might already have Tomcat installed, and then probably with the default configuration. That would mean the AJP connector is available, and http connector as well. When someone now wants to add the mod_cfml valve to their setup, I will warn them in the install/config notes to lock down their tomcat server, if they haven't done so already. Next to this, I would like to be able to make the valve secure by default, without having to rely on external settings. For this secure by default, a required shared secret key seems like a solution to me. Note : to check. I am not sure if the HTTP/HTTPS Connectors provide this shared secret thing. This may well be an AJP Connector feature only. Remote users accessing either the http connector or ajp connector (only possible if the server is not firewalled), would need to have that key in order to get the valve to create a new context. I _do_ trust the internal servers/clients, I just want to make sure that if a mod_cfml user was too lame to secure it's server, then mod_cfml isn't the weakest link to be able to hack the server. I hope that makes sense? Ok, so at this point, you only want to know, by intellectual curiosity, *how you could* theoretically, in your Valve, obtain the IP address and port of the front-end proxy server who is forwarding the original client request to your Tomcat. Oof, that was hard to write, and I hope it is correct. Actually, Christopher already provided the answer to that, in a previous post : The only way to check the caller would be to get ahold of the Socket that Tomcat is using to communicate. That's not easily done, since Tomcat wants to protect its sockets from code messing-around with the state of those Sockets. That's a clue, but not a very helpful one for you, is it ? I believe that the main issue here is that there is no such standard functionality dictated by the Servlet Specification, so there is no obligation for any Servlet Engine to provide this, and apparently thus Tomcat does not provide a way to obtain this information easily, because it doesn't have to. And according to Christopher, there may even be a deliberate attempt from the Tomcat code to prevent one being able to do such things easily, because it could potentially mess up
Re: Debugging Tomcat Running in Vagrant using Port Forwarding
On Thu, Apr 30, 2015 at 3:12 PM, David Marsh dmars...@outlook.com wrote: 8000 Is the HTTP port in development just in case you are using port 808433 Is similar for HTTPS22 Is SSH port Normally you define a free port in a user range say 9009, to be your debug port. Then you use a suitable java debugger to connect to that port. I've never used vagrant, but it sounds like you'd also need that debug port say 9009, to have port forwarding configured. Once port forwarding is configured the debug port 9009 should be accessible outside the VM. Hi David -- thanks for the response. Port 8000 is definitely the default debugging port for Tomcat though and is what I've always used before when debugging locally. I suspect there is some additional configuration I need to do in Tomcat in order to debug while it is running in a Vagrant box using port forwarding.
RE: unable to install tomcat7 on windows 2012 --- getting access denied
-Original Message- From: George Sexton [mailto:geor...@mhsoftware.com] Sent: Thursday, April 30, 2015 10:44 AM To: users@tomcat.apache.org Subject: Re: unable to install tomcat7 on windows 2012 --- getting access denied On 4/30/2015 9:40 AM, Jeffrey Janner wrote: Turn off UAC, run the install, turn back on UAC. Or, run the command prompt as an administrator and then run the script. He said he'd already tried that. I've had the UAC decide I'm not an Admin even when my user ID and/or group was a member of the Local Administrator's group on the machine. I've even seen it deny admin rights to commands run from and Admin console session - depending on the command. -Original Message- From: Eric Wood [mailto:eric.w...@irondata.com] Sent: Thursday, April 30, 2015 8:34 AM To: users@tomcat.apache.org Subject: unable to install tomcat7 on windows 2012 --- getting access denied Hi: I'm installing tomcat7 as a service on windows 2012 using the following command: Service.bat install I get an access denied message. I'm and admin on the server as well as running the command from a command prompt as admin. Any idea what may be blocking me? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- George Sexton *MH Software, Inc.* Voice: 303 438 9585 http://www.mhsoftware.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Does the securePort for Cluster/Channel/Receiver work yet?
Hi List I'm trying to add encryption to session-replication and came along this posts from January 2015 http://marc.info/?l=tomcat-userm=142063952322011w=2 as a follow up to a message from 2009. So, I'm wondering as well if this feature is really implemented. I added securePort=4500 to Receiver className=org.apache.catalina.tribes.transport.nio.NioReceiver in server.xml, restarted tomcat and checkt with netstat if something is listening on 4500. This was not the case, I only had the port specified as port= listening as before. catalina.out had log entries that the two tomcat picket up the securePort settings This was all done with tomcat-7.0.27 (sorry for being behind) This setup currently has a working session-replication, but it would be nice to have it encrypted. So is this really not implemented? Is it implemented in a newer version? Cheers Pascal
Re: Finding the Apache httpd IP address when AJP is used
Hi Christopher, Paul, On 4/29/15 10:18 PM, l...@bsoft.com.cn wrote: p.s. I asked this question, in other wording, on SackOverflow.com http://sackoverflow.com/ as well. I hope I have better luck here ;-) http://stackoverflow.com/questions/29858030/where-can-i-find-the-apach e-httpd-server-ip-from-within-a-tomcat-valve-when-ajp http://stackoverflow.com/questions/29858030/where-can-i-find-the-apac he-httpd-server-ip-from-within-a-tomcat-valve-when-ajp It's more clear from this post that you just want to make sure that the HTTP (or AJP) request is coming from localhost. If that's all you want, then change the Connector configuration so that it's only listening on localhost, like this: Connector address=127.0.0.1 ... / This will prevent any incoming connections from the outside world. Does that solve your problem? - -chris On stackOverflow, I indeed said I (just) wanted to check for 127.0.0.1/localhost. That was a simplification of the case, to keep the focus on getting the AJP request's source IP address. In real life, there will also be setups where the source IP will be different. Sorry for any confusion this may have caused. All in all, the SO question isn't really important anymore, since I now know that IP restriction wouldn't be the best way to accomplish the security I am looking for. Personally, I'd still like to know the answer, but that's only because I have spent multiple hours trying to find that IP address from inside the valve ;) Kind regards, Paul Klinkenberg - 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: unable to install tomcat7 on windows 2012 --- getting access denied
On 4/30/2015 9:40 AM, Jeffrey Janner wrote: Turn off UAC, run the install, turn back on UAC. Or, run the command prompt as an administrator and then run the script. -Original Message- From: Eric Wood [mailto:eric.w...@irondata.com] Sent: Thursday, April 30, 2015 8:34 AM To: users@tomcat.apache.org Subject: unable to install tomcat7 on windows 2012 --- getting access denied Hi: I'm installing tomcat7 as a service on windows 2012 using the following command: Service.bat install I get an access denied message. I'm and admin on the server as well as running the command from a command prompt as admin. Any idea what may be blocking me? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- George Sexton *MH Software, Inc.* Voice: 303 438 9585 http://www.mhsoftware.com
RE: unable to install tomcat7 on windows 2012 --- getting access denied
Turn off UAC, run the install, turn back on UAC. -Original Message- From: Eric Wood [mailto:eric.w...@irondata.com] Sent: Thursday, April 30, 2015 8:34 AM To: users@tomcat.apache.org Subject: unable to install tomcat7 on windows 2012 --- getting access denied Hi: I'm installing tomcat7 as a service on windows 2012 using the following command: Service.bat install I get an access denied message. I'm and admin on the server as well as running the command from a command prompt as admin. Any idea what may be blocking me? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: unable to install tomcat7 on windows 2012 --- getting access denied
Thanks, I tried turning off UAC. Same error. What did work was downloading the tomvcat7 .msi install. I was able to install successfully using it. It was an oversight not see it in the first place. The previous installation was the .zip core. Thanks for all your help. Eric -Original Message- From: George Sexton [mailto:geor...@mhsoftware.com] Sent: Thursday, April 30, 2015 11:44 AM To: users@tomcat.apache.org Subject: Re: unable to install tomcat7 on windows 2012 --- getting access denied On 4/30/2015 9:40 AM, Jeffrey Janner wrote: Turn off UAC, run the install, turn back on UAC. Or, run the command prompt as an administrator and then run the script. -Original Message- From: Eric Wood [mailto:eric.w...@irondata.com] Sent: Thursday, April 30, 2015 8:34 AM To: users@tomcat.apache.org Subject: unable to install tomcat7 on windows 2012 --- getting access denied Hi: I'm installing tomcat7 as a service on windows 2012 using the following command: Service.bat install I get an access denied message. I'm and admin on the server as well as running the command from a command prompt as admin. Any idea what may be blocking me? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- George Sexton *MH Software, Inc.* Voice: 303 438 9585 http://www.mhsoftware.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Exception in Tomcat7 when closing stream, server crashes
On 4/30/15, 10:17 AM, Christopher Schultz ch...@christopherschultz.net wrote: Osman, Lots of little things are being cleaned-up in and around the connectors as well as tcnative lately. Using the latest Tomcat will improve the stability of tcnative, because if the Java code has been mis-tracking the state of the connection, the native code can sometimes fall-over. I've tried to prevent actual crashes as much as possible, but the result in those cases is that the connection is totally trashed. I'm not sure if Tomcat is recycling those trashed connections, but every release improves the situation. It would be even better if you could move up to Tomcat 8. Lots more refactoring of the connectors has taken place there and so all connectors are more stable. I'm excited about the upcoming Tomcat 9 because the connector code has been nearly unified. This ought to make all of the connectors rock-solid . - -chris Thanks Chris, we will look into moving to Tomcat8 for our next release. smime.p7s Description: S/MIME cryptographic signature
Re: Finding the Apache httpd IP address when AJP is used
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Paul, On 4/30/15 11:27 AM, Paul Klinkenberg wrote: Hi Christopher, Paul, On 4/29/15 10:18 PM, l...@bsoft.com.cn wrote: p.s. I asked this question, in other wording, on SackOverflow.com http://sackoverflow.com/ as well. I hope I have better luck here ;-) http://stackoverflow.com/questions/29858030/where-can-i-find-the-apa ch e-httpd-server-ip-from-within-a-tomcat-valve-when-ajp http://stackoverflow.com/questions/29858030/where-can-i-find-the-ap ac he-httpd-server-ip-from-within-a-tomcat-valve-when-ajp It's more clear from this post that you just want to make sure that the HTTP (or AJP) request is coming from localhost. If that's all you want, then change the Connector configuration so that it's only listening on localhost, like this: Connector address=127.0.0.1 ... / This will prevent any incoming connections from the outside world. Does that solve your problem? - -chris On stackOverflow, I indeed said I (just) wanted to check for 127.0.0.1/localhost. That was a simplification of the case, to keep the focus on getting the AJP request's source IP address. In real life, there will also be setups where the source IP will be different. Sorry for any confusion this may have caused. All in all, the SO question isn't really important anymore, since I now know that IP restriction wouldn't be the best way to accomplish the security I am looking for. Personally, I'd still like to know the answer, but that's only because I have spent multiple hours trying to find that IP address from inside the valve ;) The only way to do this properly would be to set up an HTTPS channel between your trust web servers and your application servers, and require that the trusted web servers use SSL client certificates to successfully connect to your application servers. The client (web server) is configured to provide the client certificate, and the server (app server) is configured to require a recognized certificate. As long as your web servers are not compromised, then only your web servers will provide trusted credentials . - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVQlacAAoJEBzwKT+lPKRY5zcQAIEsv79WdddFzAZ9X3hxQSWB Jir0b9hETpNIJ3SrZB3ofiz7MVjsquk0TrWewd3xTSWY7ELguhJLDlRxnDzE6Xsz S5G1q/ViugIlbb/0fpZKt3B9LrJ1qUnxyej6+5tOpqoUco1fLZpMpSW/53xGq4my xu3W+M++7eVRCZCVjAhEJqAIATjaCmoKc8iTRVCKq5eyubbRTND/JFHqNzACcZrd jFiaYVnrOObw/Q1a8Fp/7kYFNFc7a49qcv3yUwTbpmyC3XR2vJmOrikH1bKXo/KB EeQz3MefClE7nP+3dsoCF9n6Y0OR4cASEdAETTRScnAFGfZknPL5Wa6JfGx06RM1 pz9w3mMn3y5oGNuISOmR8td0zsEFpEEemdf00Rv/fL4/dGepKHoQVSMvvcAVePcK sGFJPZGEQdeBe4h89jqvlZniRDVXvOQb0lJykDivnhqY9wgiG4TK28Y+LSrpxZhx Emh3FifqYWpVlrGQ0ii0vbHtR7Y6/kQiC+9Q2jqAlJWADz9TQ8A91CxLa+UH7K/F K0v7iS4yf+aQQvjo61wYHs34PeCvJDZ8DBHeCpmRPQmwkrm9aKW3emqubKrMgt0F 8NRq2gEulYUiI7ojM8gbrLzxKLI1nwCfh6ri0XLcOLiPgGOjvEKv9l3NbfD3A3GT vYR/xSqoOBdaKe2d2mwc =KMPh -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
