Explore NY Stream

— Kiaasa Dhanori Pune

How to Install FileAID CS Execution Server v4.2.1 on Linux

Installing the FileAID CS Execution Server 4.2.1 on Linux means preparing a 32-bit compatibility runtime, deploying Compuware's File-AID/Common Services base build, layering the 4.2.1.53 patch, and wiring an auto-start service so the data-management engine survives a reboot. This guide walks the full procedure end to end, corrects the typos that float around in the original vendor notes, and flags the modern equivalents so the setup actually works on a current-era server.

File-AID/CS (Common Services) is the distributed component of Compuware's File-AID data-management suite. The Linux Execution Server is the agent that receives jobs from the File-AID/CS workbench or scheduler and runs them against local data. Because version 4.2.1 dates from the Red Hat Enterprise Linux 5 era, it depends on 32-bit shared libraries and a Java 1.5 (JRE 5) runtime that no longer ship by default. Getting those prerequisites right is the single biggest cause of failed installs.

Before you start: prerequisites for the FileAID CS Execution Server on Linux

Sort these out before you touch the installer. Every one of them is a hard requirement, and skipping any of them produces cryptic engine startup errors later.

A dedicated service account. Create the user fileaid and the group faadm in advance. The engine must never run as root.
Resolvable hostname. The server's own hostname must resolve to a real IP. Confirm there is a line in /etc/hosts mapping the host name to its address, for example 192.168.123.123 fileaidserver.
32-bit compatibility libraries. The 4.2.1 binaries are 32-bit and need the legacy compat-libstdc++ C++ runtime.
A 32-bit Java 5 runtime (Oracle/Sun JRE 1.5.0_21, i586). The engine is hard-wired to a 1.5-class JVM and will not start on a modern JDK.
Root access for the prerequisite and service steps, plus the ability to su - to the fileaid account for the product install.

Create the account first, logged in as root:

groupadd faadm
useradd -g faadm -m -s /bin/bash fileaid
passwd fileaid

Then verify name resolution. The output should echo back the IP you expect:

getent hosts fileaidserver
hostname -f

A note on legacy versus modern

RHEL 5.4, JRE 1.5, and 32-bit-only binaries are all long past end of life. If you are building a brand-new environment, you should be deploying the current File-AID release (now part of the BMC Compuware / BMC AMI portfolio) on a supported OS, which removes the 32-bit and Java 5 gymnastics entirely. The steps below are written for keeping an existing 4.2.1 estate running, or for a faithful lab rebuild of it. Where a command depends on the old platform, the modern substitute is called out.

Step 1 - Install the 32-bit C++ compatibility library

The engine links against the old libstdc++ ABI. On a RHEL 5.x box the package comes off the distribution media; on anything newer you install it from the repos instead.

Log in as root.
Install the compatibility package. On RHEL 5.4 this is the i386 RPM from the install media:
```
rpm -ivh compat-libstdc++-296-2.96-138.i386.rpm
```
On a modern dnf/yum system the equivalent is simply:
```
yum install compat-libstdc++-296.i686
# or, newer:  dnf install compat-libstdc++-296.i686
```
Create the symbolic link the engine expects in /usr/lib so the old SONAME resolves:
```
cd /usr/lib
ln -s libstdc++-3-libc6.2-2-2.10.0.so libstdc++-libc6.1-1.so.2
```
Important: the source flag is a plain hyphen (-s). Vendor notes that were copied through a word processor often show an en-dash, which the shell rejects with "invalid option". Confirm the target file actually exists with ls /usr/lib/libstdc++* before linking; the exact version suffix can differ.

Step 2 - Install the 32-bit Java 5 runtime

The Execution Server invokes a JVM directly, and 4.2.1 was certified against Java 5. Use the 32-bit JRE 1.5.0_21 RPM bundle.

As root, make the self-extracting installer executable and run it:
```
chmod +x jre-1_5_0_21-linux-i586-rpm.bin
./jre-1_5_0_21-linux-i586-rpm.bin
```
Accept the license when prompted. The runtime installs to /usr/java/jre1.5.0_21.
Create a stable jre alias so configuration files never hard-code the exact patch level:
```
cd /usr/java
ln -s jre1.5.0_21 jre
```
Sanity-check the version it reports:
```
/usr/java/jre/bin/java -version
```
You want to see a 1.5.0_21 string. Because the binary is 32-bit, on a 64-bit OS you also need the 32-bit glibc present (yum install glibc.i686), or java fails with "No such file or directory" even though the file is right there.

Step 3 - Prepare the product directories

The engine lives under /fileaid and reads a small salt file from /etc. Both must be owned by the service account.

Create the product home and hand it to fileaid:

mkdir /fileaid
chown fileaid:fileaid /fileaid
chmod 775 /fileaid

Create the salt file the product uses to seal stored credentials, and give it to the service account:
```
touch /etc/.csysalts
chown fileaid:fileaid /etc/.csysalts
```

The original notes use the group fileaid in the chown while telling you to create a group called faadm. Pick one and be consistent. If you created faadm as the primary group, use chown fileaid:faadm throughout so ownership actually matches the account you built.

Step 4 - Install the FileAID CS Execution Server base build

Now switch to the service account and run the interactive installer from the unpacked media. Note the prompt: once you su - fileaid you are a normal user, so the shell prompt is $, not #. Vendor docs that show # after su - fileaid are simply wrong.

Become the service user:
```
su - fileaid
```
Copy the FACS_Linux_4.2.0 media to a working area such as /tmp, then go to the install folder and make the three install scripts executable:
```
cd /tmp/FACS_Linux_4.2.0/install
chmod +x facsinst.ins
chmod +x regset
chmod +x dlminstall.sh
```
Launch the installer and press Enter to begin:
```
./facsinst.ins
```

Answer the prompts. These are the values that produce a clean install into /fileaid:

Prompt	Answer
Accept the default path	`y`
Do you agree to the above terms	`y`
Command for invoking the Java virtual machine	`/usr/java/jre/bin/java`
Install into /usr/facs	`n`
Enter the product directory	`/fileaid`
OK to create this directory	`y`

Review the disk-space summary plus the source and destination paths the installer prints, then confirm to continue. When it finishes you can skip the README prompt.

Pointing the JVM at the /usr/java/jre symlink rather than the versioned folder is deliberate: if you ever patch the JRE, you re-point the link once instead of editing the engine configuration.

Step 5 - Apply the 4.2.1.53 patch to the Execution Server

The base media is 4.2.0; the supported running level is 4.2.1.53. The patch is an extract-and-replace package, so it must be applied on top of a completed base install.

As the fileaid user, copy the patch tarball and its installer into the product home:
```
cp FACS_LINUX_4.2.1.53.tar /fileaid
cp facssp53.ins /fileaid
```
Make the patch installer executable and run it from /fileaid:
```
cd /fileaid
chmod +x facssp53.ins
./facssp53.ins
```
The script unpacks the tar and overwrites the changed files in place.
Once it reports success you can remove the patch artifacts:
```
rm FACS_LINUX_4.2.1.53.tar
rm facssp53.ins
```

Step 6 - Fix permissions and the engine configuration

The patch resets some folders, so re-apply the runtime permissions the engine needs to write logs and read its configuration and data-layer modules.

Set directory permissions:
```
chmod -R 777 /fileaid/logs
chmod -R 775 /fileaid/cfg
chmod -R 775 /fileaid/dlm
chmod -R 775 /fileaid/dme
```
Security note: 777 on the log directory is what the vendor procedure asks for, but it is world-writable. On a shared or internet-facing host, prefer 770 with the faadm group owning the tree so only the service account and its admins can write.

Edit the engine launcher to point at the real data-layer module (DLM) paths:

vi /fileaid/dme/go.sh

Change the placeholder paths:

FACS_DLM32="/fileaid/dlm/Linux/32"
FACS_DLM64="/fileaid/dlm/Linux/64"

to the actual architecture folders installed by the patch:

FACS_DLM32="/fileaid/dlm/Linux/ia32"
FACS_DLM64="/fileaid/dlm/Linux/ia64"

In the same go.sh, add the encryption setting so stored credentials use AES:
```
CPWRCRYPT=AES
export CPWRCRYPT
```
Add the library search paths to the service account's profile so the JVM and engine can locate the 32- and 64-bit DLMs at every login:
```
vi /home/fileaid/.profile
```
Append:
```
LD_LIBRARY_PATH=/fileaid/dlm/Linux/ia32
LD_LIBRARY_64_PATH=/fileaid/dlm/Linux/ia64
export LD_LIBRARY_PATH LD_LIBRARY_64_PATH
```
Do not forget the export. Setting the variables without exporting them leaves them invisible to the engine process and the DLMs fail to load. The original notes omit the export line - add it.

Step 7 - Configure the Execution Server to start automatically

The engine should come up after a reboot under the fileaid account. On a RHEL 5 box this is done through the SysV rc scripts. On RHEL 7 or newer, the cleaner, supported way is a systemd unit - both approaches are shown.

As root, create a control script in /etc/rc.d and make it executable:
```
touch /etc/rc.d/rc.fileaid
chmod +x /etc/rc.d/rc.fileaid
```

Put the launch commands in it:

vi /etc/rc.d/rc.fileaid

Contents:

cd /fileaid/dme
/fileaid/dme/go.sh &   # Autostart FileAID CS Execution Server

Call the control script from /etc/rc.d/rc.local, running it as the service account:
```
su - fileaid -c "/etc/rc.d/rc.fileaid"
```
Reboot, then verify (next section):
```
reboot
```

Modern equivalent: a systemd unit

On any current RHEL/CentOS/Rocky/Alma release, skip rc.local and create /etc/systemd/system/fileaid.service instead:

[Unit]
Description=FileAID CS Execution Server
After=network-online.target

[Service]
Type=forking
User=fileaid
Group=faadm
WorkingDirectory=/fileaid/dme
ExecStart=/fileaid/dme/go.sh
Restart=on-failure

[Install]
WantedBy=multi-user.target

Then enable and start it:

systemctl daemon-reload
systemctl enable --now fileaid.service
systemctl status fileaid.service

This gives you proper logging, automatic restart, and clean shutdown - none of which the bare rc.local approach provides.

Common pitfalls when installing the FileAID CS Execution Server

Almost every failed install traces back to one of these. Check them before opening a support case.

En-dash instead of hyphen. Commands copied from formatted documents turn -s and -R into typographic dashes. Re-type flags by hand if a command reports an invalid option.
Missing 32-bit glibc on a 64-bit host. A 32-bit java or DLM fails with "No such file or directory" even when the file exists. Install glibc.i686 and libstdc++.i686.
Wrong JVM. Pointing the engine at a modern JDK (8, 11, 17) instead of JRE 1.5 causes class-version errors. The engine is certified for Java 5 in this release.
Running as root. The product is meant to run as fileaid. Installing or launching as root leaves files the service account cannot read, then the engine refuses to start.
Forgotten export. Without exporting LD_LIBRARY_PATH/LD_LIBRARY_64_PATH and CPWRCRYPT, the DLMs do not load and encryption is not applied.
Stale DLM paths in go.sh. Leaving Linux/32 and Linux/64 instead of Linux/ia32 and Linux/ia64 means the engine cannot find its data-layer modules.
Unresolvable hostname. If /etc/hosts has no entry for the server, the engine's listener can bind to the wrong interface or fail outright.

Verify the FileAID CS Execution Server is running

After the reboot, confirm the engine actually came up and is logging cleanly.

Check that the process is alive under the service account:
```
ps -ef | grep fileaid
```
You should see a java process owned by fileaid with go.sh / DME arguments in its command line. If you used systemd, systemctl status fileaid shows the same in a friendlier form.
Tail the engine's pre-execution log for a clean startup:
```
cat /fileaid/logs/Engine/DtlLog/dtlPreExecution.log
```
A healthy log shows the engine initializing, loading the DLMs from the ia32/ia64 paths, and reporting that it is listening - with no library-load or Java version errors.
Confirm the listener is up if you know the engine's port (default varies by deployment):
```
netstat -tlnp | grep java
# or, modern:  ss -tlnp | grep java
```
Finally, connect from the File-AID/CS workbench or scheduler and submit a trivial job. A successful round-trip is the real proof the Execution Server is working, not just running.

Key Takeaways

Prerequisites make or break the install: the fileaid user and faadm group, a resolvable hostname, the 32-bit compat-libstdc++ library, and a 32-bit JRE 1.5 must all be in place first.
Install order is base then patch: deploy FACS_Linux_4.2.0 as the fileaid user, then layer the 4.2.1.53 patch, then re-fix permissions and go.sh.
Point the engine at the symlinked JRE and the ia32/ia64 DLM paths, and always export the library-path and CPWRCRYPT=AES variables.
Retype command flags by hand - en-dashes from copied docs are the most common silent failure, alongside missing 32-bit glibc on 64-bit hosts.
Prefer a systemd unit over rc.local on modern Linux for reliable auto-start, and verify with ps -ef | grep fileaid plus the dtlPreExecution.log.

Frequently Asked Questions

Why does the FileAID CS Execution Server need Java 1.5 instead of a modern JDK?

Version 4.2.1 was certified against a Java 5 JVM and its bytecode and launcher options assume that runtime. A newer JDK throws unsupported class-version or option errors. Keep the certified JRE for 4.2.1, or upgrade to a current File-AID release that supports a modern Java if you want off Java 5.

Can I run the 4.2.1 Execution Server on a 64-bit Linux host?

Yes, but the binaries are 32-bit, so you must install the 32-bit support libraries - typically glibc.i686 and compat-libstdc++-296.i686. Without them, the 32-bit java and the data-layer modules fail with misleading "No such file or directory" errors even though the files exist.

The engine will not start after a reboot - where do I look first?

Check ps -ef | grep fileaid to see whether the process launched at all, then read /fileaid/logs/Engine/DtlLog/dtlPreExecution.log. The usual culprits are a missing export on the library paths, stale Linux/32 DLM paths in go.sh, files owned by root instead of fileaid, or an unresolvable hostname in /etc/hosts.

Is FileAID CS 4.2.1 still supported, and what is the modern equivalent?

This release and its RHEL 5 / Java 5 stack are long past end of life. The product line lives on under the BMC Compuware / BMC AMI banner with current releases that run on supported operating systems and modern Java, removing the 32-bit and JRE 1.5 requirements. For new builds, deploy the current version; use this guide to maintain or rebuild an existing 4.2.1 estate.

For more hands-on Linux and system-administration walkthroughs, subscribe on YouTube @explorenystream.