Update and add new Highcharts modules for use in Sisense plugins
Update and add new Highcharts modules for use in Sisense plugins The JavaScript library framework Highcharts is natively included in Sisense and is utilized in many native Sisense widgets as well as in numerous Sisense plugins. Although Sisense typically does not alter the Sisense Highcharts library version with every release, the versions of Highcharts included in Sisense may change when upgrading to a new major version release. Highcharts can load additional chart types and other types of functionality via JS module files that contain code-adding features such as additional chart types, which can be used within plugins along with additional code to create additional widget types. If a plugin utilizes a Highcharts module, you can source the module directly in the "plugin.json" file's source parameter, as shown in this example: "source": [ "HighchartModule.js", ], To determine the current Highcharts version being used in your Sisense version, you can use the "Highcharts" command in the web console while viewing any page on your Sisense server. After identifying the current Highcharts version, you can find the corresponding module hosted on the Highcharts code hosting website using the following URL format: https://code.highcharts.com/${Highcharts_Version}/modules/${module_name}.js For example: https://code.highcharts.com/6.0.4/modules/heatmap.js You can save this module and upload it to the plugin folder or replace the older module JS file simply by copying and pasting the code directly. Be sure to update the "plugin.json" file to point to the new module file if the file name has changed or if this is the first time the module is included. Simply sourcing the module file in the "plugin.json" file is sufficient to load the module into Highcharts; no further code is required to load the module.
Optimizing Docker Storage
Optimize Docker storage by efficiently managing images, containers, and volumes using docker prune commands. Over time, unused Docker objects accumulate under /var/lib/docker, leading to storage bloat. This guide provides step-by-step instructions to reclaim disk space with docker system prune, docker image prune, and more. Learn how to clean up unreferenced images, stopped containers, and unused volumes while ensuring system performance. Use caution to prevent accidental deletions. Regular maintenance keeps your Docker environment optimized.How to Check SSL Ciphers
How to Check SSL Ciphers If you have enabled SSL on Sisense side, the Nginx controller will be deployed in the default namespace. To check the currently configured ciphers run the following command and check the "nginx.ingress.kubernetes.io/ssl-ciphers:" row: kubectl -n sisense describe ingress Name: sisense-ingress Labels: app=api-gateway app.kubernetes.io/managed-by=Helm chart=api-gateway-2024.2.077 release=sisense sisense-version=2024.2.077 Namespace: sisense Address: Ingress Class: <none> Default backend: <default> TLS: sisense-tls terminates Rules: Host Path Backends ---- ---- -------- paragoninsgroup.sisense.com / api-gateway-external:8456 (10.42.140.227:8456) Annotations: kubernetes.io/ingress.class: nginx kubernetes.io/tls-acme: true meta.helm.sh/release-name: sisense meta.helm.sh/release-namespace: sisense nginx.ingress.kubernetes.io/configuration-snippet: more_clear_headers Server; nginx.ingress.kubernetes.io/proxy-body-size: 0m nginx.ingress.kubernetes.io/proxy-read-timeout: 300 nginx.ingress.kubernetes.io/ssl-ciphers: ECDH+AESGCM:ECDH+CHACHA20:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS:!AESCCM nginx.ingress.kubernetes.io/ssl-prefer-server-ciphers: true To decrypt the full list of the currently used ciphers use the string from the mentioned row with the following command: openssl ciphers -v 'ECDH+AESGCM:ECDH+CHACHA20:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS:!AESCCM' | column -t Output Example: ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD DH-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH/DSS Au=DH Enc=AESGCM(256) Mac=AEAD DH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH/RSA Au=DH Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD DH-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH/DSS Au=DH Enc=AESGCM(128) Mac=AEAD DH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1 ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1 DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 DH-RSA-AES256-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AES(256) Mac=SHA256 DH-DSS-AES256-SHA256 TLSv1.2 Kx=DH/DSS Au=DH Enc=AES(256) Mac=SHA256 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DH-RSA-AES256-SHA SSLv3 Kx=DH/RSA Au=DH Enc=AES(256) Mac=SHA1 DH-DSS-AES256-SHA SSLv3 Kx=DH/DSS Au=DH Enc=AES(256) Mac=SHA1 ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1 ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1 DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 DH-RSA-AES128-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AES(128) Mac=SHA256 DH-DSS-AES128-SHA256 TLSv1.2 Kx=DH/DSS Au=DH Enc=AES(128) Mac=SHA256 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DH-RSA-AES128-SHA SSLv3 Kx=DH/RSA Au=DH Enc=AES(128) Mac=SHA1 DH-DSS-AES128-SHA SSLv3 Kx=DH/DSS Au=DH Enc=AES(128) Mac=SHA1 AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 Check out this related content: Academy course Sisense DocumentationHow to properly reboot a k8s node(s)
As part of maintaining a healthy and robust Kubernetes (K8s) cluster, occasional reboots of nodes might be necessary. Whether for system updates, hardware maintenance, or other reasons, it's essential to follow a structured process to ensure minimal disruption to running workloads. Below is a step-by-step guide on safely rebooting nodes within a Kubernetes cluster, covering both Red Hat Enterprise Linux (RHEL) and Ubuntu systems.Health and Maintenance of Sisense Environment
Overview: Keeping your Sisense environment healthy and up to date is essential to a successful Sisense instance. This article contains general information about Sisense deployment and maintenance. Please reference the linked articles for additional information. Topics: Clean installation Upgrade Migration Clean installation When first deploying Sisense it is important to review the Installation guide and ensure any prerequisite programs are installed. Keep in mind that Sisense depends on particular Sisense roles and features which are discussed below. Technical Requirements: .NET Framework 4.6.1 (as of Sisense Version 7.3) Visual C++ Redistributable Packages Java Runtime Environment The software components above along with Windows roles and features responsible for running IIS will be installed automatically within Sisense installation. Installing Sisense Minimum Requirements For organizations that do not allow their server to access the internet can use the offline installer process. Installing Sisense Offline For additional information about keeping your Sisense environment clean and performing well, please refer to this article: Performance Issues Troubleshooting Upgrade Each version includes new features and enhancements as well as other improvements. Please read our release notes and check if there are any breaking changes in the version you are upgrading to. We strongly recommend upgrading a staging environment first so you can know how the upgrade will affect your users and your configuration before upgrading your production environment. Make sure to back up your current instance before the upgrade. Feel free to contact your Customer Success Manager (CSM) or our Sisense Support team if any additional consultation is needed. Upgrading Sisense Backing up Sisense Release Notes Migration Occasionally you come across a situation when you need to migrate Sisense to a different server (for example moving from Windows Server 2012 to Windows Server 2016). In general, Sisense consists of 2 parts: Back-End: The Back-end includes your ElastiCubes - where all of the data to analyze is stored Front-End: Front-end that includes dashboards and system configuration. Each each component can be migrated in several ways. For more information please reference the following article and follow the instructions specific to your Sisense version. Please contact your CSM if Sisense migration will make you go over limit on server licenses. Migrating SisenseRestart all Sisense Services Using PowerShell or Force Restart All Sisense Services
These instructions are for customers using Sisense On-Prem deployments. If you are a Sisense Cloud customer please reach out to Support for help with Services. Follow the instructions below to restart all Sisense services and IIS: Log on to the server with your administrator privileges. Locate PowerShell and run it as administrator (right click -> Run as administrator). Copy and run the following commands: Get-Service | where {($_.name -like "*sisense*" ) -or ($_.Name -like "*elastic*" )} | Restart-Service iisreset /noforce Follow the instructions below to Force Stop all Sisense Services and then Start them again: Log on to the server with your administrator privileges. Locate PowerShell and run it as administrator (right click -> Run as administrator). Copy and run the following commands: Get-Service | where {($_.name -like "*sisense*" )} | Stop-Service -Force Get-Service | where {($_.name -like "*sisense*" )} | Start-Service
EKS Kubernetes Version Upgrade
EKS Kubernetes Version Upgrade Below are steps on how to upgrade the Kubernetes version in AWS Kubernetes Service (EKS). First, ensure that the current version is compatible with the K8S version you will upgrade to. If not, upgrade the Sisense version compatible with the K8S version first! It is also strongly recommended to have the cloud_autoscaler feature enabled in your configuration yaml. Upgrade the control plane of the cluster, open the EKS page, and find your cluster. You should see the 'Upgrade now' link if a newer major K8S version is available. Click on that link and select the version (Please note, usually, only one version is available because you cannot jump over versions). Click the Update button, and you should see a similar information bar as the one below: The cluster is being updated: As the control plane upgrade is being completed, the cluster version should also update as well: If needed, the kubectl version (client binary file) should be updated manually. It should be one value more or less than the server version, e.g., for the cluster with EKS 1.23, you can use kubectl 1.22, 1.23, and 1.24. Please notice that the nodes are still running the previous Kubernetes version. Open the cluster page and go to the Compute tab. You should see the upgrade options for NodeGroups. Click on update for every node group and select "Force Update." The new nodes should appear while the old nodes are cordoned. Eventually, you should see only new nodes running: If you had the cloud_autoscaled feature disabled, run the installer with the new node names.
