RE: Need help for a problem on migrating from Tomcat-8 to Tomcat-9
Hi Mark, Thanks for your explanation and suggestion. For my use case, I have used the below option and its working fine. = --ServiceUser="LocalSystem" = Thank you very much for showing the way. Regards Rajib -Original Message- From: Mark Thomas Sent: 26 February 2024 14:23 To: users@tomcat.apache.org Subject: Re: Need help for a problem on migrating from Tomcat-8 to Tomcat-9 [You don't often get email from ma...@apache.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] On 26/02/2024 06:11, Saha, Rajib wrote: > Hi Experts, > > In our product, we are using Tomcat [OriginalFileName: prunsrv.exe] for > creating a service[Say, Service-A]. It's a huge product running in market for > last 20 years. > We are in progress of moving from Tomcat-8 to tomcat-9. > > When we are creating the Service-A with Tomcat-8 [tomcat8.exe]. In "Services" > desktop app, we can see the service is created with "Local System" in "Log On > as". > When we are creating the Service-A with Tomcat-9 [tomcat9.exe]. in "Services" > desktop app, we can see the service is created with "Local service" in "Log > On as". > > Looks like "Local service" has less power than "Local System". > Due to it, Service-A created with Tomcat-9 failing for several operation > inside product. That should be a security concern. Local System is broadly equivalent to local administrator. You generally don't want to be running Tomcat under Local System. > Can somebody suggest, how we can create a service with tomcat-9, with the > privilege of "Local System"? Have you looked at the documentation? https://tomcat.apache.org/tomcat-9.0-doc/windows-service-howto.html Look for "--ServiceUser" Mark - 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: configuring Tomcat 9.0.85 for debugging
On 2/26/2024 2:18 PM, Mark Caruso wrote:
If anyone has guidance for configuring Tomcat 9.0.85 for debugging please send
it along. I am running the program under Ubuntu 20.04. I am not sure the
guidance on the internet for modifying catalina.sh is right. My goal is to
then attach a debugger from Netbeans 16 and debug my web app.
Thank youMark
Mark,
In my opinion, running a service-oriented (systemd for Ubuntu 20.04) or
package-installed Tomcat for development and debugging is not ideal.
In no particular order, you'll run into:
1. Start / stop issues (you'll need sudo)
2. Log permissions (looking at logs may be an issue)
3. Deployment permissions (more about that below)
Also, NetBeans 21 just came out and is available via snap. Is there any
reason to run NetBeans 16?
NetBeans allows you to start up a Tomcat instance in normal, debug, or
profile mode from the IDE. It does this by using the Tomcat-provided
catalina.(sh/bat) script. That's going to be an issue if you're using a
package-installed Tomcat.
In the NetBeans server setup, you can either use shared memory or JMX
(and specify the port) for a Tomcat server. By default, NetBeans will
use shared memory for a Tomcat running on the same machine.
NetBeans deploys an application to Tomcat that it controls by copying a
context.xml file over to the appropriate location in a Tomcat installation
($CATALINA_HOME/conf/Catalina/localhost/appname.xml) with an appropriate
docBase. For example, if you are running a Maven project, that docBase
will be:
${project.basedir}/${project.build.directory}/${project.artifactId}-${project.version}
This enables a project to be deployed quickly, as well as enables hot
reloads if you enable compile on save.
Deploying and redeploying a web application for debugging may run into
permissions issue if you're using a package-installed version of Tomcat.
So, in summary:
1. Download Tomcat from tomcat.apache.org
2. Extract and install it in a reasonable spot underneath your home
directory
3. Edit server.xml to change any ports (if necessary)
4. Edit tomcat-users.xml to add a user with a manager-script role (see
comments in file)
5. Configure NetBeans to use the freshly installed Tomcat
Debugging is then simply starting Tomcat in debug mode. This is how I
work on Windows, Ubuntu, Fedora, and have people set up on MacOS.
. . . just my two cents
/mde/
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: configuring Tomcat 9.0.85 for debugging
> On Feb 26, 2024, at 16:18, Mark Caruso wrote: > > If anyone has guidance for configuring Tomcat 9.0.85 for debugging please > send it along. I am running the program under Ubuntu 20.04. I am not sure the > guidance on the internet for modifying catalina.sh is right. My goal is to > then attach a debugger from Netbeans 16 and debug my web app. Might want to start with the Tomcat FAQ, in particular this page: https://cwiki.apache.org/confluence/display/TOMCAT/Troubleshooting+and+Diagnostics - Chuck
configuring Tomcat 9.0.85 for debugging
If anyone has guidance for configuring Tomcat 9.0.85 for debugging please send it along. I am running the program under Ubuntu 20.04. I am not sure the guidance on the internet for modifying catalina.sh is right. My goal is to then attach a debugger from Netbeans 16 and debug my web app. Thank youMark
Re: A curious case of Tomcat 10.1.x NIO(1) acceptor not stopping clearly on some setups
Thank you, that clears things up. I did not think about implication of using wildcard. I will try to use explicit addresses from now on. You learn something new every day! Cheers, Michał On 26.02.2024 09:48, Mark Thomas wrote: On 25/02/2024 18:18, Michał Szymborski wrote: On quick inspection the acceptor thread (https://github.com/apache/tomcat/blob/10.1.x/java/org/apache/tomcat/util/net/Acceptor.java#L128) was listening on [/[0:0:0:0:0:0:0:0]:39033] , which was correctly picked up at first, but then this local address got transformed: 0.0.0.0 is shorthand for "all configured IP address". Tomcat can't use that address to establish a connection to the Acceptor thread so it has to try and deduce a valid IP local address from the network configuration information exposed through the Java APIs. https://github.com/apache/tomcat/blob/10.1.x/java/org/apache/tomcat/util/net/AbstractEndpoint.java#L1164 It started picking up interfaces to use, and it stopped at the first non-loopback non-link local address, which also happens to be some sort of a bridge network for one of my VMs. I don't quite know why there is no routing set up, but this interface should not have been picked in the first place. It is a local IP address so as far as Tomcat can see it should be valid to connect to the Acceptor. I'll take a look at how it works on my work laptop with MacOs, but I'd wager a guess that some corporate VPNs have interfaces which have messed up routing as well. Can't tell if it's a bug or a feature, but it sure is unexpected. Making this timeout for acceptor shutdown configurable would be one sort of band-aid. It is configurable. socket.unlockTimeout. Documented default is 250ms although looking at the code it appears there is a minimum of 2000ms - need to see why that is. Configuring a specific address (even 127.0.0.1) for the Connector would also address this. Mark - 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: Need help for a problem on migrating from Tomcat-8 to Tomcat-9
On 26/02/2024 06:11, Saha, Rajib wrote: Hi Experts, In our product, we are using Tomcat [OriginalFileName: prunsrv.exe] for creating a service[Say, Service-A]. It's a huge product running in market for last 20 years. We are in progress of moving from Tomcat-8 to tomcat-9. When we are creating the Service-A with Tomcat-8 [tomcat8.exe]. In "Services" desktop app, we can see the service is created with "Local System" in "Log On as". When we are creating the Service-A with Tomcat-9 [tomcat9.exe]. in "Services" desktop app, we can see the service is created with "Local service" in "Log On as". Looks like "Local service" has less power than "Local System". Due to it, Service-A created with Tomcat-9 failing for several operation inside product. That should be a security concern. Local System is broadly equivalent to local administrator. You generally don't want to be running Tomcat under Local System. Can somebody suggest, how we can create a service with tomcat-9, with the privilege of "Local System"? Have you looked at the documentation? https://tomcat.apache.org/tomcat-9.0-doc/windows-service-howto.html Look for "--ServiceUser" Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: A curious case of Tomcat 10.1.x NIO(1) acceptor not stopping clearly on some setups
On 25/02/2024 18:18, Michał Szymborski wrote: On quick inspection the acceptor thread (https://github.com/apache/tomcat/blob/10.1.x/java/org/apache/tomcat/util/net/Acceptor.java#L128) was listening on [/[0:0:0:0:0:0:0:0]:39033] , which was correctly picked up at first, but then this local address got transformed: 0.0.0.0 is shorthand for "all configured IP address". Tomcat can't use that address to establish a connection to the Acceptor thread so it has to try and deduce a valid IP local address from the network configuration information exposed through the Java APIs. https://github.com/apache/tomcat/blob/10.1.x/java/org/apache/tomcat/util/net/AbstractEndpoint.java#L1164 It started picking up interfaces to use, and it stopped at the first non-loopback non-link local address, which also happens to be some sort of a bridge network for one of my VMs. I don't quite know why there is no routing set up, but this interface should not have been picked in the first place. It is a local IP address so as far as Tomcat can see it should be valid to connect to the Acceptor. I'll take a look at how it works on my work laptop with MacOs, but I'd wager a guess that some corporate VPNs have interfaces which have messed up routing as well. Can't tell if it's a bug or a feature, but it sure is unexpected. Making this timeout for acceptor shutdown configurable would be one sort of band-aid. It is configurable. socket.unlockTimeout. Documented default is 250ms although looking at the code it appears there is a minimum of 2000ms - need to see why that is. Configuring a specific address (even 127.0.0.1) for the Connector would also address this. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
