Sophos Anti-Virus for UNIX: System reports not found or cannot load library error

If your UNIX system returns not found or cannot load library messages when you try to run Sophos Anti-Virus for UNIX/Linux, you probably need to change your system settings.

The following sections are covered:

Applies to the following Sophos products and versions

Sophos Anti-Virus for Unix

Ensure that the environment variables in your login script or profile include the directories that Sophos Anti-Virus uses.

  • PATH should include /usr/local/bin
  • MANPATH should include /usr/local/man
  • LD_LIBRARY_PATH should include /usr/local/lib.

In AIX, the library environment variable is LIBPATH and in HPUX it is SHLIB_PATH.

On some systems, such as FreeBSD and Linux, you can enable Sophos Anti-Virus to use the Sophos Anti-Virus shared libraries by running ldconfig. This may require editing of /etc/ld.so.conf.

Adding environment variables

If any of the above variables are not included, add them to the environment variable(s) as shown in the examples below. Do not alter any of the existing settings.

If you are running the sh, ksh or bsh shell, enter:

PATH=$PATH:/usr/local/bin

export PATH

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib

export LD_LIBRARY_PATH

If you are running the csh or tsh shell, enter:

setenv PATH [values]:/usr/local/bin

setenv LD_LIBRARY_PATH [values]:/usr/local/lib

Where, [values] are the existing settings.

You should make these variables system-wide. To do this, amend /etc/login or /etc/profile.

Note: If you do not have a login script, you will need to reset these values every time you restart the server.

If you’ve spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.

This is invaluable to us to ensure that we continually strive to give our customers the best information possible.

Related:

NetWorker Module for Databases and Applications: Sybase server connection failed for XXXXX. Check user name, password, server name, Sybase Installation directory and Sybase Server

==> If the script is present and have all line commented just un-comment and/or add the lines:

# Setting open file limit and max process

ulimit -n 65535

ulimit -u 65535

LANG=en_US.UTF-8

export LANG

==> If not present, create a new one with the lines as:

Add to networker startup script in /nsr/nsrrc

#!/bin/sh

#

# Called via Networker startup script

#

# Source Bourne shell scripts to set the environment variables

#

# Setting open file limit and max process

ulimit -n 65535

ulimit -u 65535

LANG=en_US.UTF-8

export LANG

Related:

7023391: Reflection end-user folders get created in C:Micro FocusReflection instead of under My Documents

This problem is caused because the user’s My Documents location has been redirected to the root of the C: drive. (This is an unusual location and is not typically used as the destination of Re-directed My Documents)

The path for the Reflection user configuration files is determined by a Windows registry key called “UserDir” under HKEY_LOCAL_MACHINESoftwareWow6432NodeWRQReflection. This value is typically set to the default of %personalfolder%Micro FocusReflection. This unique variable allows the Reflection software to resolve the location of the configuration files “on-the-fly” as it may be changed from defaults for the user and variable prevents issues that can occur if a fixed or static entry is used to point to the end-users Documents folder. The %personalfolder% is not a Microsoft Windows environment value, and actually pre-dates the Windows PersonalFolders variable. The %personalfolder% value will typically expand to the same value used by the Windows Environment variable called “UserProfile” (via a Windows 32-bit API call) and can also resolve to where the users Re-directed My Documents is located, if it is on a network drive. Problems only occur if the the Re-directed My Documents is pointed to the root of the C: drive, as all other locations will work correctly.

To resolve the issue set the following registry keys:

HKEY_LOCAL_MACHINESoftwareWow6432NodeWRQReflection

Key Name: UserDir:

Key Value: %UserProfile%DocumentsMicro FocusReflection

HKEY_LOCAL_MACHINESoftwareWow6432NodeWRQReflection

Key Name: LogDir:

Key Value: %UserProfile%DocumentsMicro FocusReflection

Note: The trailing backslash on this path is important. Without the trailing backslash the pathing will not work correctly.

Related:

3078409: Handling ndsd (eDirectory) core files on Linux and Solaris

Sometimes the reason ndsd crashes is due to memory corruption. If this is the case, it is necessary to add variables setting to the ndsd environment to put the memory manager into a debug state. This will help to ensure that ndsd generates a core at the time the corruption occurs so the module that caused the corruption can more easily be identified in the core.

If ndsd cores due to stack corruption, Novell Technical Support will request that you add the appropriate memory manager setting and wait for another core to re-submit.

Linux

To set the necessary memory checking variable on Linux:

Systemd – SLES 12 / Redhat 7 or later: Modify the “env” file located in the /etc/opt/novell/eDirectory/conf directory, then restart the eDirectory instance. ( See 2nd bullet under “Please refer to the following notes:” for details. )

MALLOC_CHECK_=3



SysVinit
– SLES 11 / RedHat 6 or earlier: Modify the pre_ndsd_start script and the following at the very top, then restart the eDirectory instance.

MALLOC_CHECK_=3

export MALLOC_CHECK_

Please refer to the following notes:

  • The contents of the pre_ndsd_start script are sourced into ndsd at the time ndsd loads. Be aware that any permanent settings will be overwritten if left in the ndsd script the next time an eDirectory patch is applied while the pre_ndsd_start script will not be modified. For this reason changes to the ‘ndsd’ script itself should not be made. This is the purpose of the pre/post_ndsd_start scripts.

  • eDirectory on SLES 12 or RHEL 7: You must add all environment variables required for the eDirectory service in the env file located in the /etc/opt/novell/eDirectory/conf directory.

  • MALLOC_CHECK_=3 should NOT be left permanently. Once the cores have been gathered, remove this setting from the modified script and restart ndsd. This environment variable can have a performance impact on some systems due to the increased memory checking. In eDirectory 8.8, it will cause ndsd to revert back to using malloc instead of tcmalloc_miminal which was added to enhance performance.

    Another side effect of using MALLOC_CHECK_=3 is the possibility of increased coring. Malloc will cause ndsd to core whenever a memory violation is detected whether or not it would have caused ndsd to crash under normal running conditions.

    To verify this ndsd environment variable is set properly while ndsd is running, do the following as the user running the eDirectory instance (‘root’ most of the time):

    strings /proc/`pgrep ndsd`/environ | grep -i MALLOC_CHECK_

    The command above will not work on a server with multiple eDirectory instances (or ndsd processes). To check a particular instance find that instance’s process’s PID and use that directly. For PID 12345 the command would be the following:

    strings /proc/12345/environ | grep -i MALLOC_CHECK_

    After ndsd has cored, to verify the core file had the ndsd environment variable set, do the following:

    strings core.#### | grep -i MALLOC_CHECK_

    Bundle the core with MALLOC_CHECK_=3 set as in step 2.

    For more information on Malloc check see: TID 3113982 – Diagnosing Memory Heap Corruption in glibc with MALLOC_CHECK_

  • eDirectory 8.8.5 ftf2 (patch2) the location of the pre_ndsd_start has been moved from /etc/init.d to /opt/novell/eDirectory/sbin/.

Solaris

In current code, eDirectory uses libumem as the memory manager.

To configure libumem for debugging add the following to the pre_ndsd_start script at the top and restart ndsd:

UMEM_DEBUG=default

UMEM_LOGGING=transaction

export UMEM_DEBUG UMEM_LOGGING

Submit a new core with these settings in place.

Changing the location where cores files are generated

In certain situations it may be desirable to change the location where core files are generated. By default ndsd core files are placed in the dib directory. If space in this directory is limited or if another location is desired, the following can be done:

mkdir /tmp/cores

chmod 777 /tmp/cores

echo “/tmp/cores/core”> /proc/sys/kernel/core_pattern

This example would now generate the core. <pid> file in /tmp/cores

To revert back to placing cores in default location:

echo core > /proc/sys/kernel/core_pattern

Symbol build of ndsd libriaries



In some cases, a core file generated while running libraries with symbols included may be necessary to analyze the core.

This is particularly true when analyzing cores generated by the 64 bit version of ndsd since the parameters aren’t located at a specific location.

The symbol versions of the libraries can be obtained from Novell eDirectory backline support.

Related:

7021332: Session Server Restarts on IBM AIX

To resolve this issue, increase the process memory limit before starting the session server by setting the LDR_CNTRL environment variable.

For example, LDR_CNTRL=MAXDATA=0x7000000 configures a 2 GB process memory limit. In the sample startup script below, see the inserted red lines.

INSTALL_DIR=/opt/attachmate/verastream

BIN_DIR=$INSTALL_DIR/hostintegrator/bin



echo "Starting Verastream"

$BIN_DIR/atstart -start logmgr



export LDR_CNTRL=MAXDATA=0X70000000

$BIN_DIR/atstart -start server

unset LDR_CNTRL



$BIN_DIR/atstart -start hostemul

$BIN_DIR/atstart -start mgmtserver

For additional information about the LDR_CNTRL environment variable, see http://publib.boulder.ibm.com/tividd/td/ITAME/GC32-0846-00/en_US/HTML/am39_perftune11.htm.

For more information about VHI memory usage, see Technical Note 10131.

For information about configuring a system daemon startup script to run VHI services automatically, see http://docs2.attachmate.com/verastream/vhi/7.1sp2/en/topic/com.attachmate.vhi.vmc.help.online/tasks/vhi_mc_session_svr_sys_daemon.xhtml.

Related:

  • No Related Posts

7021334: Error VHI 4300 “The scripting manager failed to initialize”

If your symptoms indicate failure with the Java scripting manager, see Recommended Solution for Java Issue and Alternative Solution for Java Issue. If your symptoms indicate failure with the .NET scripting manager, see Solution for .NET Issue.

Recommended Solution for Java Issue

To resolve this issue, set the environment variable vhi_embedded_xmx to a lower value, such as -Xmx512m. However, if a smaller value is already set (from a previous version), try removing the setting or increasing the value instead.

Windows

On Windows, set this variable at Control Panel > System and Security > System > Advanced (or Advanced system settings) > Environment Variables > System variables. The exact steps may vary, depending on your operating system version and Control Panel view.

Figure 2. New System Variable dialog

Figure 2. New System Variable dialog

Note: On Windows Server 2003 or Windows XP, to make the environment variable available to the Local System account that runs services, you must restart the system (see http://support.microsoft.com/kb/821761).

UNIX/Linux

On UNIX/Linux, you may need to export the environment variable so that it is available to the process that runs the VHI session server.

Alternative Solution for Java Issue

If you do not have permissions to set system environment variables or restart the system, and are running version 7.1.221 or higher, you can edit JVM configuration files instead. Note: This procedure will need to be repeated after installing any future upgrade or hotfix, as the configuration files will be reset to default values.

  1. Locate your destool.conf and sesssrvr.conf files in the appropriate directory:

Windows: C:Program FilesAttachmateVerastreamHostIntegratoretc

UNIX/Linux: /opt/attachmate/verastream/hostintegrator/etc

  1. Open each file in a text editor.
  2. Locate the following existing line:
scriptmgr.java.additional.4=-Xmx768m
  1. Modify the parameter to use a lower value. For example:
scriptmgr.java.additional.4=-Xmx512m
  1. Save changes.
  2. Restart the session server service as described in Technical Note 10004. Close and restart any instances of the Design Tool application.

Note: If the system environment variable vhi_embedded_xmx (or vhi_embedded_classpath or vhi_embedded_libpath) are set, they take precedence over the .conf file contents.

Solution for .NET Issue

Ensure that your system has Internet access (such as ability to make outbound connections through a firewall) so it can connect to the system crl.verisign.net (for the Certificate Revocation List at VeriSign).

If you are running version 7.6.44 or earlier and your organization’s policies prohibit Internet access, complete the following steps to disable Authenticode verification:

  1. In a text editor, open the clrscriptserver.exe.config file located in C:Program FilesAttachmateVerastreamHostIntegratorlibdotnet.
  2. In the <runtime> section, insert the following line:
<generatePublisherEvidence enabled="false"/>

For example:

<runtime>

<generatePublisherEvidence enabled="false"/>

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

Note: Beginning in version 7.6.47, this setting already exists by default.

  1. Save changes and restart the Session Server service or Design Tool application. For more information about starting services, see Technical Note 10004.

Related:

7022689: kerberos authentication error after upgrading to SLES12SP2

A krb5 PTF patch has been created to allow for backward compatibility. An environment variable needs to be set along with using updated code.

To set this environment variable for your SAP environment, you need to determine which shell your sap processes are using.

You can see which shell they are using in the /etc/passwd file.

If using bash shell environment, you can set this globally by adding the following to /etc/bash.bashrc.local

export GSSAPI_ASSUME_MECH_MATCH=1

If using csh, you can add the following to the /etc/csh.cshrc.local

setenv GSSAPI_ASSUME_MECH_MATCH 1

Related:

7022430: dxcmd terminates unexpectedly with error 143 when executing large queries

This document (7022430) is provided subject to the disclaimer at the end of this document.

Environment

eDirectory 8.8.8.x

eDirectory 9.0.x

Identity Manager 4.5

Identity Manager 4.6

Situation

When executing the following command:

dxcmd -user admin.sa.system -password password -sendevent ‘driver.driverset1.system’ /root/query.xml /root/output.log

if the query submitted takes over 2 minutes to complete, the process fails with error 143 and no result file is generated.

Resolution

Increase the timeout value by setting the environment variable NCPCLIENT_REQ_TIMEOUT to a number of seconds larger than the total time the query takes.

Setting the environment variable permanently for dxcmd can be accomplished by adding export NCPCLIENT_REQ_TIMEOUT=value to the dxcmd script /opt/novell/eDirectory/bin/dxcmd.

It is also possible to set the variable manually in the terminal from which the script is being executed by executing export NCPCLIENT_REQ_TIMEOUT=value prior to executing dxcmd.

Alternatively the variable can be set as user or system variable depending on the use case.

Cause

By default a NCP connection has a timeout of 115 seconds. If the total time of the query plus returning results exceeds that value, dxcmd exits with error 143. By setting the NCPCLIENT_REQ_TIMEOUT to a larger value (for example 1200), you increase the amount of time that the operations is allowed to use to complete. Since the value is in seconds, a setting of 1200 would allow the operation to take up to 20 minutes.

Additional Information

The command:

dxcmd -sendevent <driver dn> <input filename>

submits a document to the driver’s Subscriber channel, bypassing the driver cache. The document gets processed ahead of anything that might be in the cache at the time of the submission. The submission will fail if the driver is not running.

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.

Related:

Automate deployment on ibm bpm process servers- dev , SIT, stage and then PROD?

I have 4 different environments Dev, SIT,stage,production.

I want to promote same snapshot to all the environments. All the environments have different environment variables values.

How can i configure the server and environment variables mapping.
eg:- on dev server- dev environment variables should be picked automatically.
on PROD server – prod environment varibales should be picked automatically.

Related:

Privilege Elevation Challenges in Tasks

I need a solution

Is the below expected behavior?

GSS 3.2 RU3 Run Script tasks when run as specific user, that is also a local administrator of the target machine, does not load an elevated process.

It’s easy to duplicate by running a Run Script task, as a specific user, that is local administrator, maximized, and with a ‘Pause’ statement. If you look at that cmd.exe session in task manager, you will see that the elevated column shows ‘No’.

When tested against a DS 6.9 SP6 installation, the process was run in an elevated session.

So, I’m curious. Where is the bug? Within an old DS install or within the new GSS environment?

Thanks

0

Related: