Page History

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.

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.

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.