Error Code 1302 received after upgrading to DLP 14.x or 15.x

Products

Data Loss Prevention

Issue/Introduction

After upgrading to DLP version 14.5, deleting the upgrade resources directory (i.e. /opt/SymantecDLP/Protect/upgrades/<folder_name>) causes symlinks to break for libraries that DLP is dependent on. This will prevent File Reader from starting until the deleted directory structure is recreated.
You may see Error Code 1302 after upgrading to DLP 14.5 or later.

Code: 1302
Summary: File Reader failed to start
Detail: Error starting File Reader. /opt/SymantecDLP/Protect/lib/native/libcontentextractionjni-14.5.0.so: libboost_thread-gcc49-mt-1_54.so.1.54.0: cannot open shared object file: No such file or directory No incidents will be detected.

NOTE: This can be different than 14.5.0 for later versions.

FileReader0.log:

Oct 3, 2016 10:25:18 PM com.vontu.messaging.FileReaderSetup initialize
SEVERE: (DETECTION.3) Failed to initialize Detection
java.lang.UnsatisfiedLinkError: /opt/SymantecDLP/Protect/lib/native/libcontentextractionjni-14.5.0.so: libboost_thread-gcc49-mt-1_54.so.1.54.0: cannot open shared object file: No such file or directory
   at java.lang.ClassLoader$NativeLibrary.load(Native Method)
   at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937)
   at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1822)
   at java.lang.Runtime.load0(Runtime.java:809)
   at java.lang.System.load(System.java:1086)
   at com.vontu.cracker.jni.JniLoader.loadLibrary(JniLoader.java:55)
   at com.vontu.cracker.jni.NativeObject.<clinit>(NativeObject.java:32)
   at com.vontu.cracker.jni.EngineContext.<init>(EngineContext.java:34)
   at com.vontu.cracker.NativeExtractionEngine.<init>(NativeExtractionEngine.java:57)
   at com.vontu.cracker.NativeExtractionEngine.<init>(NativeExtractionEngine.java:38)
   at com.vontu.detection.ExtractionEngineFactoryLoader.loadExtractorFactory(ExtractionEngineFactoryLoader.java:34)
   at com.vontu.messaging.FileReader.initializeContentExtractionServices(FileReader.java:563)
   at com.vontu.messaging.FileReader.initializeContentExtractionServices(FileReader.java:512)
   at com.vontu.messaging.FileReader.start(FileReader.java:348)
   at com.vontu.messaging.FileReaderSetup.initialize(FileReaderSetup.java:105)
   at com.vontu.messaging.FileReader.main(FileReader.java:273)
Oct 3, 2016 10:25:18 PM com.vontu.logging.LocalLogWriter write
SEVERE: File Reader failed to start. Error starting File Reader. /appvg/dlp/Protect/lib/native/libcontentextractionjni-14.5.0.so: libboost_thread-gcc49-mt-1_54.so.1.54.0: cannot open shared object file: No such file or directory No incidents will be detected.

Environment

This phenomenon only impacts Linux systems that have been upgraded to DLP version 14.x or 15.x. This can impact Enforce servers and Detection servers.

Cause

Per the Symantec DLP 14.5 Upgrade Guide for Linux, steps on page 32 and page 34 indicate that the root upgrade scripts should be run after upgrade has completed on Enforce and Detection servers. These root upgrade scripts create symlinks for depency libraries that DLP 14.5 needs to function in a Linux environment.

In DLP version 14.5, these root upgrade scripts replace a file called "symantec-dlp-x86_64.conf" as seen in example snippet:

# This is to update the ld.so.conf.d file we create. It can only be updated by root so cannot be in any other part of the upgrader.
rm -rf /etc/ld.so.conf.d/symantec-dlp-x86_64.conf
echo -e "/opt/SymantecDLP/Protect/updates/update-id-52/../../../Protect/lib/native/\n/opt/SymantecDLP/Protect/updates/update-id-52/../../../Protect/plugins/contentextraction/ImageExtractorPlugin/x86_64\n/opt/SymantecDLP/Protect/updates/update-id-52/../../../Protect/plugins/contentextraction/Verity/x86_64\n/opt/SymantecDLP/Protect/updates/update-id-52/../../../jre/lib/amd64/server/" > /etc/ld.so.conf.d/symantec-dlp-x86_64.conf

As you can see in this example, the root upgrade script is creating a new "symantec-dlp-x86_64.conf" file which includes references to a relative path for the /opt/SymantecDLP/Protect/updates/update-id-52 directory.

It is not uncommon for system administrators to delete the upgrade resource folder (i.e. the "update-id-52" directory in this example) to save disk space after an upgrade. Removing or modifying this directory structure will break the symbolic links being referenced in the symantec-dlp-x86_64.conf file.

Resolution

If this directory structure is modified or deleted, then the workaround here is to simply recreate the folder name that was used at time of the upgrade. The following steps can be used to determine the folder name and recreate it as needed:

Log on to the Linux server in question and launch Terminal
Run the following command to view contents of the existing symantec-dlp-x86_64.conf file:

[root@rhel-enforce ~]# cat /etc/ld.so.conf.d/symantec-dlp-x86_64.conf
The output will show the relative paths being used by the symbolic links, for example:

[root@rhel-enforce ~]# cat /etc/ld.so.conf.d/symantec-dlp-x86_64.conf /opt/SymantecDLP/Protect/updates/update-id-52/../../../Protect/lib/native /opt/SymantecDLP/Protect/updates/update-id-52/../../../Protect/plugins/contentextraction/ImageExtractorPlugin/x86_64 /opt/SymantecDLP/Protect/updates/update-id-52/../../../Protect/plugins/contentextraction/Verity/x86_64 /opt/SymantecDLP/Protect/updates/update-id-52/../../../jre/lib/amd64/server/
NOTE: The update-id-52 will be different for different versions, so see what is in the "symantec-dlp-x86_64.conf" file folder for the update folder and make sure to use the same naming structure.
Run the following command to recreate the directory structure as shown in the above output:

[root@rhel-enforce ~]# mkdir /opt/SymantecDLP/Protect/updates/update-id-52
(Optional) Set the appropriate permissions for the "protect" user for DLP on this folder, run command:

[root@rhel-enforce ~]# chown protect:protect /opt/SymantecDLP/Protect/updates/update-id-52
Rerun Postupgrade script
Be sure to restart DLP services for this change to take effect