On Fri, May 1, 2020 at 10:48 AM Zer0Cool <[email protected]> wrote:
> I am looking for help with the proper way to "install" and configure > tomcat 9 > with Guac 1.1.0 on RHEL/CentOS 8.x. > > As RHEL 8.x removed the tomcat package from the repos, I now find myself > downloading the .tar.gz and extracting it out like so: > > tar xvf apache-tomcat-9.0.34.tar.gz -C /usr/share > ln -s /usr/share/apache-tomcat-9.0.34/ /usr/share/tomcat > > Using the symlink so that I can just update the symlink to > /usr/share/apache-tomcat-9.x.x with 9.x.x being newer. Later I have the > service file setup and chown tomcat user/group for /usr/share/tomcat. > > My standard practice is just to download the latest version, unpack it and move it to /opt/tomcat. If you want to keep up with specific versions you can unpack it to /opt and then link /opt/tomcat to the version. I generally don't put it in /usr anywhere (even /usr/local), since that seems to be more for packages and distribution-specific stuff. This is probably more habit and history-driven than anything else, but I tend to install all my custom builds/installs in /opt, including Tomcat, Guacamole, etc. > From here, I am a bit uncertain were particular files/directories should be > placed, mostly pertaining to tomcat/guacamole's relationship. > > Ex: previously in CentOS 7 with tomcat 7 installed from repo I had a > /var/lib/tomcat directory with a /webapps directory. Do I need to mimic > that > or should I be using /usr/share/tomcat/webapps in its place? Previously I > used this path for the JKS path (/var/lib/tomcat/webapps/.keystore), so if > I > dont need to make this dir, were should the JKS path be? > > This is another reason why I think just unpacking it into /opt is a simpler way to go - that way, you know *everything* is under that /opt/tomcat directory and you don't have to worry about updating a bunch of configs and placing things in the right place. > Along with the above, do I need to use the parameters "keystoreFile" and > "keystorePass" within server.xml? Were should server.xml be located? > Previously, (CentOS 7/tc 7) server.xml was in /etc/tomcat/, should its > still > be or should I be using /usr/share/tomcat/config/ (off hand I think this > was > the dir I found server.xml in)? > > Also, do I need to add to the server.xml blocks for "RemoteIPValve and > "ErrorReportValve" like I had done in CentOS/TC 7? > > Yes, this must be done if you want the Client IP to be passed through, at least for the RemoteIPValve. Not sure about the ErrorReportValve. > Also, do I need to worry about changing permissions on any Tomcat > files/dirs > and/or Guacamole content? > > TLDR - what should the directory setup for TC 9 be in CentOS/RHEL 8.x and > what directories should I be using for Guacamole 1.1.0 (and beyond) related > to Tomcat? > > Not for Guacamole specifically, but you should *definitely* change permissions of the directory to a non-root user, and run Tomcat as a non-root user. Running Tomcat as root is a really bad idea, and there's no reason at all it needs root privileges to run. I tend to make a "guacamole" user that I use for running both Tomcat and guacd, but this is entirely up to you. Background - I am working on upgrading my install script for Guac on > RHEL/CentOS 7.x to 8.x. The Tomcat related code for my 7.x script can be > seen: > > https://github.com/Zer0CoolX/guacamole-install-rhel/blob/master/guac-install.sh > mainly in the functions from line 1297 to 1329. There are some blocks of > code that create dirs/symlinks at 1073-1080 and 1207-1213 too. > > I am trying to wrap my head around accomplishing the same results (or > improving them) as with that code but for RHEL/CentOS 8.x, Tomcat 9.x and a > manual install of TC. > > Any help would be most welcome, currently stuck on trying to properly setup > Tomcat/Guacamole as they relate to each other. Thanks > > Very nice! I think this a great help to the community, particularly to folks who may be less experienced in spinning up Linux workloads, Java application servers, etc. I appreciate your involvement in the community! -Nick
