Checking the Prerequisites
Checking the Prerequisites
Below are the prerequisite checks to perform before installing Sisense.
|
# |
Prerequisite |
Adherence Check |
|---|---|---|
|
1 |
The server's base OS and the Sisense application must comply. Version compatibility is stated for both the major and minor versions. |
Run the following command: The results show you the OS, and its major/minor version. Check to ensure compatibility. For example: Operating System: Ubuntu 18.04.4 LTS For the list of prerequisites, see Minimum Requirements for Sisense in Linux Environments. |
|
2 |
The supported architecture is limited to x86-64/AMD64. |
Run the following command: The results show you the OS, and its major/minor version. Check to ensure compatibility. For example: Architecture: x86-64 |
|
3 |
A sudo-enabled user account is required for each server on which Sisense will be deployed. It is recommended that the user has a UID/GID of 1000 (not mandatory). |
Run the following command: Check that the user has the correct rights. The user must have the right so run “ALL” as shown below:
Also, run the following command to check whether the user is assigned a UID/GID of 1000: |
|
4 |
The Sisense installation directory must be owned by the user used for installing Sisense. So when the package is unpacked, you need to be logged in with the right user. Note if you by mistake run the installation with the wrong root user owning it you will receive an error such as: The directory '/home/sisense/.cache/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag. The directory '/home/sisense/.cache/pip' or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag. |
Run the following command: Confirm that all files/directories are owned by the installation user (in the example below, the user name is sisense): drwxr-xr-x 4 sisense sisense 4096 Aug 24 12:50 . drwxrwxr-x 5 sisense sisense 4096 Jul 25 17:32 .. -rw-r--r-- 1 sisense sisense 3546 Jun 14 15:03 cloud_config.yaml -rw-r--r-- 1 sisense sisense 3719 Jun 14 15:03 cluster_config.yaml -rw-r--r-- 1 sisense sisense 4941 Jun 14 15:03 config.yaml -rw-rw-r-- 1 sisense sisense 13323294 Nov 11 2020 helm-v3.4.1-linux-amd64.tar.gz drwxr-xr-x 15 sisense sisense 4096 Jun 14 15:03 kubespray -rw-r--r-- 1 sisense sisense 3092 Jun 14 15:03 openshift_config.yaml -rw-r--r-- 1 sisense sisense 2376 Aug 24 12:52 single_config.yaml -rw-rw-r-- 1 sisense sisense 2037870 Aug 24 13:16 sisense-ansible.log -rwxr--r-- 1 sisense sisense 35710 Jun 14 15:03 sisense.sh If the directory is wrongly assigned to the root user, you can either fix the ownership or delete it and unpack the installation package again with the correct installation user logged in. To fix the ownership of the folder to the correct user, run the command:
and then confirm correct user ownership with: |
|
5 |
For an upgrade/reinstallation, the same sudo-enabled user account that was used for the previous installation must be used for the new one. |
Run the following command: Check that the user that owns the directory is not root. |
|
6 |
For a single-node installation, the secondary disk must have a permanent mount entry in the fstab file. |
Run the following command: Check that a second disk shows as mounted. For example: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 250G 0 disk |-sda1 8:1 0 512M 0 part /boot/efi |-sda2 8:2 0 1.9G 0 part /boot `-sda3 8:3 0 247.6G 0 part |-sisense_vg-sisense 253:0 0 87.8G 0 lvm /opt/sisense |-sisense_vg-root 253:1 0 143.1G 0 lvm / `-sisense_vg-placeholder 253:2 0 16.8G 0 lvm sr0 11:0 1 1024M 0 rom If it is not shown, make sure that the correct entry appears in the /etc/fstab file, for example: UUID=2A46-DB7A /boot/efi vfat umask=0077 0 1 /dev/mapper/sisense_vg-sisense /opt/sisense ext4 defaults 0 2 Repeat the procedure for mounting a disk as a prerequisite for single-node installation. |
|
7 |
If Sisense was uninstalled, the server must be rebooted prior to reinstalling. |
After an uninstall, reboot the server on which the new installation is to be performed before performing the new installation. Use the uptime command to confirm that the server has rebooted prior to starting the new installation. |
|
8 |
Avoid installing other applications on the server. If other applications were installed, verify that there are no TCP/UDP port conflicts. |
Check that the ports do not conflict with your other applications. Validate that the disabling of the firewall (performed by the Sisense installation) is ok and approved by the customer. You can run the following command to review which ports are in use: For the full list of ports, see: Minimum Requirements for Sisense in Linux Environments. |
|
9 |
Sisense must be installed on a clean, dedicated server. Third party components and other non-Sisense capabilities running on the server might conflict with the proper installation and operation of the Sisense platform. |
Check that Sisense is installed on a clean server, that is, a server that only had the proper OS installed on it. |
|
10 |
Sisense can run on one of the compatible OS versions in the list provided, and should not be installed on a modified OS (e.g., a Kernel that has been specifically modified to harden security, such as applying a CIS (Center for Internet Security) benchmark). |
For the list of supported OS versions, Minimum Requirements for Sisense in Linux Environments. |
|
11 |
If you are installing Sisense on top of an infrastructure that already has Kubernetes installed, make sure that the Kubernetes version that is running is supported for the given Sisense release. |
Run the following command to check the Kubernetes version: Kubectl version
|
For more information about actions to perform before installing Sisense, watch this video:
Next Steps
.r.
