Because of the way the installation is dissected and distributed, I found it easier to install from a download and use my own service file. Having the installation in one place also allows me to run concurrent instances of Tomcat having different versions, and/or to save old versions for future reference and know it's all self contained. apt-get installations of tomcat required I memorized three different locations for the installation .. that wasn't good in my case. I'm sure others will have alternative opinions.
On 6/18/21, tomcat-li...@thomas.freit.ag <tomcat-li...@thomas.freit.ag> wrote: > Hi Onno, > > On 18.06.21 07:07, Sugar Moose wrote: >> I am using Ansible role robertdebock.tomcat to install Tomcat. This role >> uses archives from the Tomcat site to install Tomcat. I have always >> thought that this is a fine approach but the customer has pointed out that >> a package install is preferred because it makes installing security >> updates easier. This customer uses Ubuntu 18.04 and the position of the >> InfraOps engineers is that installing Tomcat from the official Ubuntu >> repository is always preferred. > > Installing Tomcat directly from the archives is easy and straight forward, > in my opinion it should be perfectly fine using upstream as source (you > should at least verify the download). > Especially, if Tomcat plays a major role of the system (i.e. running some > business critical applications), I would always stick to the version from > Tomcat archives. You will end up with a more > recent version of Tomcat, as it is actively developed, those versions will > contain all security fixes (directly from the team and without possible > backporting of security fixes). If you use > CATALINA_HOME and CATALINA_BASE variables you can easily switch between > different Tomcat versions, making it very easy to manage updates and > possible necessary rollbacks. > > I would only stick to the distro-provided packages, if it is a small (in > other words not that important) application running in Tomcat. Just for > reference: With Ubuntu 18.04, you would end up > with 9.0.16 vs. 9.0.48 (Tomcat project) or 8.5.39 vs. 8.5.68 (Tomcat > project), which is about 2 years old software. For any errors you might get > on distro packages, first hint would most > likely be to update to a recent Tomcat version. Even if security fixed are > backported by the distro, you would end up with versions missing a lot of > fixes and improvements. > >> I don't know how exactly using apt packages makes life a lot easier when >> it comes to security updates. I think it depends. If Ansible manages the >> version it looks more or less the same to me. The Ansible role would have >> an var for example tomcat_version and the value would determine the what >> version is on the system. Updating Tomcat using Ansible would be same >> proces: update tomcat_version var and provision the node. When Ansible is >> not managing the version but is used for example only for the initial >> install using Ansible package module it becomes a bit of a puzzle to >> figure out how this would work. And also would have some drawbacks. >> Ansible is good at configuration management and orchestration for example. >> Apt not really. > > Yes, Ansible is much more flexible for managing the configuration and > deployment-parts. You will need something for that task, even if you use the > distro-provided packages. > >> What is the position / what are the thoughts on this in the Tomcat >> community? On the Tomcat website I could find no information on package >> install. I don't think a recommended installation approach is mentioned >> there. > > In short: If your application in Tomcat is important, use the Tomcat archive > up to date versions, if not distro packages might be sufficient. This might > be challenging, if Tomcat is managed by > the infrastructure team (from my experience, there is always a trend towards > the distro packages, sometimes with the argument support by the distro). It > might help, if managing the Tomcat can > be done by the applications support/devops team (however, that might depend > on the organisation constraints). > > hth, > Thomas > > --------------------------------------------------------------------- > 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
