Bug 64395 - Windows Installer should offer an option to select a service account
Summary: Windows Installer should offer an option to select a service account
Status: NEW
Alias: None
Product: Tomcat 9
Classification: Unclassified
Component: Packaging (show other bugs)
Version: unspecified
Hardware: PC All
: P2 enhancement (vote)
Target Milestone: -----
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-30 06:14 UTC by Christoph.vonWittich
Modified: 2021-01-27 23:11 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph.vonWittich 2020-04-30 06:14:24 UTC
The current installer installs the Tomcat Service by using the LocalSystem account.
This account is high privilege account and should not be used for production webservers.

Please add an option to select a service user (including gMSA - https://docs.microsoft.com/de-de/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) and set appropriate directory permissions for this user to run tomcat.
Comment 1 Mark Thomas 2020-04-30 08:41:44 UTC
(In reply to Christoph.vonWittich from comment #0)
> The current installer installs the Tomcat Service by using the LocalSystem
> account.
> This account is high privilege account and should not be used for production
> webservers.

This is not correct. As of the switch to Commons Daemon 1.2.0 around the middle of last year, Tomcat uses "Local Service", not "Local System". This can still be changed, e.g. via Tomact9w.exe, if required.

We previously looked at providing an option to select a user in the installer under bug 55969. The conclusion then was that the work required did not justify the benefit given the change to "Local Service". That doesn't mean that a patch to provide that feature would be rejected - quite the opposite - just that the committers are likely to have higher priorities.
Comment 2 Christoph.vonWittich 2020-04-30 08:45:43 UTC
>The conclusion then was that the work required did not justify the benefit given the >change to "Local Service".

Not when you just have to manage a single instance of Tomcat...

I have to manage at least 30, and it takes a long time to update each of them as every update is a complete reinstall and all settings like directory permissions, java options, jdbc drivers, etc. are lost - even when you select "Keep my files".
Comment 3 Mark Thomas 2020-04-30 08:58:49 UTC
You would be better off not using the installer and using separate CATALINA_HOME/CATALINA_BASE.

Upgrades would then be:
- unpack new binary
- stop service
- modify service to point to new binary
- start service

There is a (very) brief outline here:
https://tomcat.apache.org/tomcat-10.0-doc/windows-service-howto.html#Multiple_Instances

The users mailing list is the place to discuss this further if this is of interest. There are probably things we can do in terms of script support to make this even smoother.

Back to the original enhancement request...

Patches are welcome but if you plan to wait for one of the Tomcat committers to write the patch I think you'll have a long wait.
Comment 4 Bill Stewart 2021-01-27 23:11:47 UTC
If I may be so bold, I designed an alternative Windows installer package (with approval from ASF) that is designed to simplify scenarios like this. Upgrade is simple:

1. Update timestamps of config files you don't want to overwrite, and
2. run installer and everything is upgraded automatically.

There's no need to uninstall/reinstall unless you need to "downgrade," and the installer supports installing multiple instances (each of which gets its own entry in the Windows program list).

https://github.com/Bill-Stewart/ApacheTomcatSetup

The alternative installer has a couple of easily worked around minor bugs that will get fixed in the next version.