-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Yuri,
On 12/10/12 11:22 PM, Yuri E wrote: > 2012/12/10 Daniel Mikusa <dmik...@vmware.com> > >> On Dec 10, 2012, at 11:28 AM, André Warnier wrote: >> >>> Yuri E wrote: >>>> 2012/12/7 André Warnier <a...@ice-sa.com> >>>>> Christopher Schultz wrote: >>>>> >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>>>> >>>>>> André, >>>>>> >>>>>> On 12/7/12 1:55 PM, André Warnier wrote: >>>>>> >>>>>>> I am relatively familiar with tomcat under Windows, >>>>>>> and if your explanations of what works and what >>>>>>> doesn't above are exact, then I don't know either. >>>>>>> >>>>>> One possibility: during the installation, the user chose >>>>>> to bind only to localhost instead of 0.0.0.0. >>>>>> >>>>> Aaaah. Yes, and that choice probably only exists in the >>>>> Service >> installer. >>>>> That would fit. And he would see that with netstat. >>>>> >>>>>> >>>> "netstat -abn" results: -- running Tomcat on console: TCP >>>> 0.0.0.0:8009 0.0.0.0:0 LISTENING >> 3844 >>>> [java.exe] TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING >> 3844 >>>> [java.exe] TCP 127.0.0.1:8005 0.0.0.0:0 LISTENING >> 3844 >>>> [java.exe] -- running Tomcat as Service: TCP 0.0.0.0:8009 >>>> 0.0.0.0:0 LISTENING >> 488 >>>> [Tomcat7.exe] TCP 0.0.0.0:8080 0.0.0.0:0 >>>> LISTENING >> 488 >>>> [Tomcat7.exe] TCP 127.0.0.1:8005 0.0.0.0:0 >>>> LISTENING >> 488 >>>> [Tomcat7.exe] >>> >>> Well, Chris, that was a worthy guess, but apparently it is not >>> the >> reason here. >>> >>> Didactic section : >>> >>> In both cases above (running in a console window and running >>> as a >> Service), we have Tomcat listening : >>> - on port 8080, all interfaces, all IP addresses. That's the >>> HTTP >> Connector >>> (see in server.xml) - on port 8009, all interfaces, all IP >>> addresses. That's the AJP >> Connector >>> (see in server.xml) (and maybe you don't need that one, and >>> can >> comment it out) >>> - on port 8005, only on the "localhost" address. That is the >>> "shutdown >> port", which is limited to listening for calls originating from >> the same physical host, for security reasons (so that nobody can >> shut down your Tomcat from the internet e.g.) >>> >>> And the reason why in one case the process is "Tomcat7.exe" >>> and in the >> other case it is "java.exe" : >>> - when Tomcat runs as a Service, there is a "service wrapper" >>> involved, >> which "wraps around" the java process (and Tomcat in it), and >> which provides the special functions that Windows Services must >> provide for Windows (like listening to Windows "star/stop >> service" messages etc..). This wrapper is a copy of the >> procrun.exe program, renamed to "tomcat7.exe" for convenience. >>> So when you run Tomcat as a Service, Windows really starts >> "tomcat7.exe", and tomcat7.exe runs java.exe which runs tomcat. >>> >>> -- end of didactic section -- >>> >>> >>> To summarise what is happening now : >>> >>> 1) Tomcat running in a console window : a) can be accessed >>> from a browser running on the same machine b) can be accessed >>> from a browser running on another machine >>> >>> 2) Tomcat running as a Windows Service : a) can be accessed >>> from a browser running on the same machine b) but cannot be >>> accessed from a browser running on another machine >>> >>> while in both cases it is listening to 0.0.0.0:8080 >>> >>> It it was a DNS issue, then both 1-b and 2-b wouldn't work. >>> But only 2-b >> doesn't work. >>> If it was a firewall issue or similar, we'd have the same. If >>> it was an issue of the java parameters or others used when >>> starting >> tomcat as a service, then both 2-a and 2-b would not work. But >> 2-a works. >>> >>> Some weird MS security rule, applying to services but not to >>> regular >> processes ? >>> >>> Yuri, can you repeat for us which exact URL's you are using to >>> access >> Tomcat, in each of the cases above ? >>> >>> 1-a : 1-b : 2-a : 2-b : >>> >>> and how the problem shows up, when "it does not work" ? >> >> Also, if you have a firewall running on the server, how is it >> configured? Do you have a rule to allow tcp on port 8080? I ask >> because some firewalls will restrict at the application level as >> well as the port level. For example, only "java.exe" is allowed >> to listen on port 8080. >> >> Dan >> >> >>> >>> >>> --------------------------------------------------------------------- >>> >>> >>> 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 >> >> > I couldn't access your answers at work today. Then I decided to > make the tests at home. I installed Tomcat exactly as the same > manner as I installed on my work PC. The problem was the same. But > then I read the answers, and I saw something that I've not tried > yet. The Windows Firewall. I turned off the Firewall, and > everything worked very well. Now I have to test the same solution > on my work PC. Yup: Windows, like many other OSs, can whitelist certain processes for binding to certain ports. For some reason, a binary not on the whitelist appears to still be able to bind to the port, but nothing can access it. The Windows firewall has a configuration screen where you can modify those binaries that may do certain things. You'll need to duplicate the "java.exe" one that we are fairly sure works (or maybe "javaw.exe") and change the binary to "Tomcat7.exe". - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlDHQSAACgkQ9CaO5/Lv0PBckgCgiokfKX6mwgJAgq4F27+XwTSn 7/QAn2LEqDU2JQ1JLrtyNOwihTv2Kv42 =1GjK -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
