SAP BusinessObjects XI 3.1/BI 4.x installation prerequisites and best practices (Linux/Unix)
As promised in SAP BusinessObjects XI 3.1/BI 4.x installation prerequisites and best practices [Windows] here is a continuation of the pre-requisites & best practices document for SAP BOE XI 3.1 and BI 4.x on Linux/Unix based environments.
The same concept applies as for Windows servers, which is to allow the installer to run as uninterrupted as possible with respect to the OS parameters/settings. There are certainly deeper checks required on a *nix environment, however these should be taken care of during the build-up of a server and are mostly common for any application. However, here are a few of them which have been observed to cause issues if not set correctly.
I’ve not included sizing in this as I wanted to keep this document for OS related parameters and configurations only however if you wish to learn more about how to size an environment you can visit: **http://service.sap.com/sizing.
To start with, the hardware and software configuration of the server or client machine that we’re installing SAP BusinessObjects on must be supported. SAP provides a supported platforms guide or “Product Availability Matrix” (PAM) for several products.
These can be found at the following URL: http://service.sap.com/pam
You can also refer the following KBA: 1338845 – How to find Product Availability Matrix (PAM) / Supported Platforms Document for SAP BusinessObjects Products
Here is an example of a page from the PAM document. Along with the compatibility with SAP and 3rd party softwares, for Unix, OS patch requirements and additional patches/libraries that are required are also mentioned here. The product version is also included in the screenshot.
Ensure you’re viewing the details of the correct OS / patch when viewing a PAM or Supported Platforms Guide.
**Visit the Sizing URL to know more about SAPS.
B. USER / GROUP
The most crucial piece in a Unix BO installation is the user. BO cannot be installed on Unix using the root user nor is root access required post-installation to run BusinessObjects. Hence, it is best practice to have a separate user for an installation for example: bo41adm.
Add this user to an existing group or create a group separately for the BO user. bo41adm will own the BO installation and be used to run all scripts, etc.
The user must have sufficient rights on the following:
a. Installation directory
b. Installation media
The following rights must be given:
A minimum right’s value of 755 is sufficient.
C. HOSTNAME & hosts FILE ENTRY
Just like Windows, BusinessObjects is identified on a server by its hostname. Hence, we must ensure that the system has a valid and resolvable hostname.
To set a coherent hostname (e.g. bidev01, etc.), you can use the command:
hostname <desired name>
Nextly, make sure the hostname is associated with the machine’s IP address in the hosts file, wherever relevant.
The hosts file on a Linux/Unix system is found in /etc.
This is a necessary step because if the hostname is not resolved over the network, many services will not be accessible. Client tools have been observed to fail to connect to a BO cluster / host if it cannot be resolved.
If you’re choosing to export SLD data to Solution Manager, the hostname is what is included in the “.xml” output of the BOBJ SLD REG batch. If the hostname/ip address mapping is not correct, the SLD will contain incorrect data cause errors ahead.
Most access to a Unix based server take place through a terminal emulator / console such as PuTTY. This can be used to access a BO server from any machine that has network access to that server. This means that we’re installing remotely.
It is advised to use the terminal emulator from a machine which is in the same network as the server (or within the DMZ, if applicable). However, in scenarios where this is not possible, ensure that there is NO restriction on the network path that may hamper the installation.
…or Security-Enhanced Linux.
SELinux is an access control implementation for a Linux kernel. It provides security restrictions for certain kinds of executions.
For more details: Security-Enhanced Linux – Wikipedia, the free encyclopedia
Note that SELinux is only for RedHat Enterprise Linux.
Disable SELinux prior to perform a BusinessObjects installation. To disable on RHEL5, follow the below steps:
- Click on System on the main taskbar.
- Select Administration.
- Click on SELinux Management.
- Choose to keep this disabled.
See the below screenshot of how to disable SELinux on a RedHat Linux 5 OS.
You could also perform this using the command prompt:
To check the status of SELinux: sestatus
To change the SELinux status, you can make the changes in /etc/selinux/config
For more details you can check the following link:
F. RESOURCE LIMITS:
A Linux/Unixoperating system has a methodology of sharing the available resources within a set of users, groups, domains, etc.. These resources can be split up to allow optimum usage of the OS that has various applications installed on it and managed by different users.
A user can be allocated a certain amount of resources. The user can play around within the range that it has been provided by setting the required value (soft limit) and can set it upto the admin restricted maximum value (hard limit).
For example, in RHEL5, we can see the limits using the ulimit -a command.
The limits configuration file is here: /etc/security/limits.conf
The root user has access to make changes to the configuration in this file.
It is recommended to set the limits to unlimited for BusinessObjects installations as mentioned in the Installation guides.
There have been issues observed with BI 4.0 installations on Linux which led to random services crashing. These issues were overcome by increasing the limits. See below KBAs:
In the PAM document, you will also find a list of LOCALES that BusinessObjects is supported with. A compatible locale needs to be set prior to installation.
To check the locale, you can type the command: locale
To set a specific locale, you can type the command: locale <value>; For example: locale en_US.utf8
The PAM document mentioned in point A presents a list of the supported locales.
H. USER PROFILE / PATH:
Needless to say, however the user profile must have the correct access related requisites in terms of the Unix executables, etc. Improper access to the user’s bin usually causes issues when the installer internally sources, runs scripts, etc.
Have observed issues where if the path to the “ping” command is not added to $PATH, installations do not proceed with a INS00293.
I hope the above helps towards a successful installation. Above recommendations are based on several instances observed while troubleshooting support issues where the installation had failed and one or more of these options had helped reach to completion!
Being Linux/Unix environments there is a lot to be ensured from the OS perspective as well as the rights. The basic idea here is to allow the product to install without any hindrances, access issues, etc. from the OS level.