Web Application Platform is a component of Teamwork Cloud. Apache Tomcat is the web server environment used by Web Application Platform. Frequent patching of Tomcat is needed to address the latest vulnerabilities (CVE) discovered.
For detailed instructions, refer to the Upgrading and Patching Apache Tomcat documentation:
- For Teamwork Cloud 22x and older, find the latest patch for Tomcat 9.X
- For Teamwork Cloud 24x and newer, find the latest patch for Tomcat 10.X.
Patching on Linux servers can be performed using a script that we provide. Both online and offline patching are supported. Windows Servers will require a manual patching process.
Cassandra startup issue could be due to several reasons. The service log should provide clues on what is causing the issue. Use the journalctl -u cassandra command to look through the service startup log for errors.
For JVM error, make sure the default Java version is set to support your Cassandra version (Java 11 for 4.X and Java 1.8 for 3.X).
For JNA errors, such as “failed to link C library against JNA” or fatal error SIGSEGV, system mount is the issue. Verify whether /tmp and /dev/shm are mounted with the noexec option (command: findmnt /tmp). Note that the Cassandra installation script will also check these mounts.
Cassandra uses the Java Native Access (JNA) library to access platform-specific shared libraries. During startup, both /tmp and /dev/shm are used for execution.
While /tmp can be configured to another path, /dev/shm must be remounted with exec. To set the tmp directory to an alternate path, find or create a path where Cassandra will have permission to execute in. Then, append the following line to the cassandra-env.sh file in /etc/cassandra/conf.
JVM_OPTS="$JVM_OPTS -Djna.tmpdir=[NEW_PATH] -Djava.io.tmpdir=[NEW_PATH]"
Before restarting Cassandra, make sure to delete all the existing commitlogs. Previous startup attempts would have created numerous commitlog files.
Note that if /tmp or /dev/shm is mounted as noexec, changing permission or ownership of the directory will not resolve the issue. The directory either has to be remounted with noexec removed or use the solution provided above.
Error “/etc/rc.d/init.d/functions: No such file or directory” is related to RHEL 9. However, in some configurations, it can occur on older releases. You can try to solve it by installing initscripts:
dnf install initscripts
or by copying /etc/rc.d/init.d/functions file from an older machine.
Use the log file utility to automatically gather and package all the relevant log files. Specific log file paths can be found in File locations.
Download the desired version of Temurin OpenJDK (https://adoptium.net/temurin/releases/). For most cases, the JRE package is adequate.
Unpack the tar.gz file on the Linux server (/opt path is recommended)
Add the newly-installed Java release as an alternative:
alternatives --install /usr/bin/java java <path to new java>/bin/java <priority number>
Set as the default system Java:
alternatives --config java
Open the upgrade path diagram in a new tab and use it to determine what steps are required for the upgrade. Upgrading from older versions will require database migration and Cassandra upgrade. Minor upgrades will only involve uninstalling the current version and installing the latest version.
Teamwork Cloud 2021x Refresh 2 Hot Fix 5 supports Cassandra 4.0.X out of the box. For 2021x Refresh 2 to connect to Cassandra 4.1.X, add the following parameter to the end of the application.conf file in <install_root>/<product>/configuration.
esi.persistence.cassandra.enable-check-version = false
If the following error is encountered during installation:
Error: Could not find or load main class com.zerog.lax.LAX Caused by: java.lang.ClassNotFoundException: com.zerog.lax.LAX
The best solution is to download the latest installer and installation scripts for your version. This issue is caused by newer versions of Java 11 and 17. Our scripts and installers (.bin) have been updated to address this issue.
If you are unable to use the latest installer and scripts, then add the following additional Java environment parameter when executing the installer. This environment parameter should either be added to the installation script, or on the command line if you are executing the .bin installer file directly.
JAVA_TOOL_OPTIONS=-Djdk.util.zip.disableZip64ExtraFieldValidation=true ./$INSTALLER
It is possible to install Teamwork Cloud without internet access, provided that the prerequisite packages are available locally. Access to a locally-managed repository server is a recommended for offline installation. Linux packages often have dependencies that are pulled and installed automatically when connecting to a repository. Manual download of Linux packages may require a trial-and-error process of retrieving dependencies.
Access to repository server
If you have access to a locally-managed repository server, go through the installation sections and download all prerequisite packages listed. Edit the installation scripts and replace all hyperlinks with local path to the downloaded package. Finally, execute the installation script. The local repository server will resolve all packages and dependencies needed during installation.
Manual installation
If your only option is to manually install all packages needed, then you will need to first download all the prerequisite packages from a machine with internet access. Then, as each package is installed, you will need to make a note of the dependencies required. This will be an iterative process in order to find all the dependencies that are needed to complete the installation.
To prepare for manual installation, an internet-accessible machine is initially needed to download all the required packages. This machine should mirror the environment of the deployment server. A mirrored environment will accurately resolve package dependencies. Use the DNF Download Plugin (dnf-plugins-core) to retrieve packages.
sudo dnf download –resolve <package-name>
The command structure above will download the main package and any dependencies that is required. Dependencies are dictated by the Linux environment. If the deployment server has a very different Linux environment than the download machine, then resolving package dependencies can be a tedious process.
This error is typically due to an incorrect address entry in the authentication whitelist. Verify addresses specified for authentication.redirect.uri.whitelist in authserver.properties file are correct.
You may encounter an error message similar to the one shown below when running Teamwork Cloud in FIPS Mode. PKCS12 keystore creation and usage are blocked in FIPS Mode for Java 11 and older versions.
PBES2 AlgorithmParameters not available
First, make sure the initial installation was able to generate a self-signed certificate and keystore. Look for keystore.p12 and teamworkcloud.crt files in <install_root>/TeamworkCloud/configuration. If these files were not generated, run the genkey script in <install_root>/TeamworkCloud/script/linux. Check for the keystore.p12 and teamworkcloud.crt files again and change ownership to twcloud (or other username that you chose during installation.) Once these two files are generated, version 2024x should be able to run in FIPS Mode.
If the genkey script is not able to generate the self-signed certificate and keystore, set the system Java version to 17 (alternatives --config java) and try again.
For 2022x Refresh 2, append the following line to the end of the jvm.options file located in <install_root>/TeamworkCloud.
-Dcom.redhat.fips=false
This configuration will allow Teamwork Cloud to use PKCS #12 keystore in FIPS Mode. Similar configurations will have to be set for Cassandra if encrypted communication is enabled.