Sisense Community logo
    • Community Feedback
    • Chapters
    • Events
    • Forums
      • Help and How To
      • Product Feedback Forum
      • Strategy & Use Cases
    • Blogs
    • KB Docs
      • KB Docs
      • Add-Ons & Plug-Ins
      • APIs
      • Best Practices
      • Blox
      • CDT
      • Cloud Managed Service
      • Data Models
      • Data Sources
      • Embedding Analytics
      • How-Tos & FAQs
      • Onboarding
      • PySisense
      • Security
      • Sisense Administration
      • Sisense Intelligence & AI
      • Troubleshooting
      • Widget & Dashboard Scripts
    • Support
    • Learning
      • Sisense Academy: Free Courses and Certifications
      • Official Developer Documentation
      • Official Product Documentation
      • Official Sisense Youtube Channel
      • Sisense Compose SDK Playground
      • Official Sisense Discord
    • Use Case Gallery
    Discussions
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   
    Discussions
    • TagsChevronRightIcon
    Upgrades
    • Blog banner
      • News & UpdatesChevronRightIcon

      Have you heard about Sisense Intelligence?

                                       

      AI that builds with you: Meet Sisense Intelligence If you’re an app builder or product manager embedding analytics into your products, you know today’s users expect more: intuitive insights, smart visualizations, and fast answers– all without leaving the product experience. That’s where Sisense Intelligence comes in. Sisense Intelligence is our new suite of AI-powered capabilities designed to accelerate every stage of the analytics journey– from development to insight delivery– all within the Sisense platform. Whether you're a product leader, developer, or data expert, these features are built to help you create seamless, intelligent analytics experiences at scale. What’s inside Sisense Intelligence? A unified framework of powerful tools, including: Assistant : A conversational interface for building dashboards and exploring data with natural language. Narrative : Auto-generated summaries that highlight key takeaways from charts and widgets. Forecast & Trend : Tools to spot patterns and predict what’s ahead. Explanation : Pinpoint drivers of change across key metrics. These features are connected by a common goal: to help builders move faster, deliver smarter, and create product experiences users love. Want to go deeper? Join us for a live webinar on June 5 at 11:00 AM ET: Register now → Build with AI: What’s new (and what’s next) in the Sisense platform See how AI-powered analytics can accelerate your product strategy– schedule a demo . If you're an existing Sisense customer, reach out to your Customer Success Manager. Can't wait? Watch this 90-second video highlighting our newest AI capabilities: Visit trust.sisense.com for security details.

      Community_Admin
      Community_AdminPosted 1 year ago
      0
               
      • Sisense AdministrationChevronRightIcon

      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 a Highcharts code hosting website using the following URL format: https://cdn.jsdelivr.net/npm/highcharts@${Highcharts_Version}/modules/${module_name}.js For example: https://cdn.jsdelivr.net/npm/highcharts@10.3.3/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.

      Jeremy Friedel
      Jeremy FriedelPosted 2 years ago • Last reply 1 year ago
      2
               
    • Blog banner
      • News & UpdatesChevronRightIcon

      Community upgrade announcement

                       

      Community upgrade announcement Sisense KB Doc UI Enhancement Hello, Sisense Sherlocks!  I have an exciting announcement! Recently, we sent out a survey asking for your feedback. Many of you responded, and one of the top issues we heard is that while there is great content in the community, it can be hard to find.  We are doing something about that! Our first step is to improve how our KB docs are organized. To help you find relevant content, KBs are now divided into broad categories instead of a long list of individual documents. We are also reducing the number of KB Doc labels to make them easier to find and discover and to reduce visual clutter. You can also click on a specific label, which will show you all the KBs tagged with that label and allow you to follow that topic if you want, which will send you updates when KBs with that label are published. [ALT Text: Screenshot of the Sisense Community KB Docs page, displaying a search bar and categorized knowledge base sections, including Add-ons & Plug-Ins, Best Practices, Data Models, Security, Troubleshooting, and more.]   We hope you like these changes. This is only the first of many improvements we have in store, so keep your eyes open for more exciting news in the coming weeks! Thank you, and have a wonderful day! DRay

      DRay
      DRayPosted 1 year ago • Last reply 1 year ago
      1
               
      • TroubleshootingChevronRightIcon

      Client-server version difference exceeds supported skew (+/-1)

                                               

      Version d ifference between the client (1.xx) and the server (1.xx) exceeds the supported minor version skew of +/-1 Sometimes during the upgrade process, you can see such a warning: sisense@node1:~/sisense-L2024.3.0.501$ ./sisense.sh single_config.yaml [2025-02-24 10:49:56] Preparing System ... [2025-02-24 10:49:56] Linux user: sisense [2025-02-24 10:49:56] Validating Sudo permissions for user sisense ... [2025-02-24 10:49:56] User sisense has sufficient sudo permissions [2025-02-24 10:49:56] Detecting Host OS ... [2025-02-24 10:49:56] OS: Ubuntu, Version: 22.04 [2025-02-24 10:49:56] Validating OS and its version [2025-02-24 10:49:57] Can proceed with RKE process ... [2025-02-24 10:49:57] Validating that namespace name is all lower case ... [2025-02-24 10:49:57] detected lock on dpkg, releasing it Enter the password for user sisense and press [ENTER]: Using password for Sisense Installation ... [2025-02-24 10:50:02] Verifying Python packages exist ... [2025-02-24 10:50:06] Installing required pip libraries [2025-02-24 10:50:09] Ensuring sisense main directory /opt/sisense exist [2025-02-24 10:50:09] Fixing /opt/sisense ownership to all files WARNING: version difference between client (1.29) and server (1.26) exceeds the supported minor version skew of +/-1 WARNING: version difference between client (1.29) and server (1.26) exceeds the supported minor version skew of +/-1 This means that kubectl version installed on the server differs by more than 1  version from Kubernetes, which is not officially supported. To fix this issue, you’ll need to set the following value in the configuration yaml file: update_k8s_version: true And run the update as usual

      Andriy Soroka
      Andriy SorokaPosted 1 year ago
      0
               
      • TroubleshootingChevronRightIcon

      Error in ingress-nginx-controller pod after upgrading Sisense to L2024.1

                                               

      Error in ingress-nginx-controller pod after upgrading Sisense to L2024.1: main.go:64] port 80 is already in use. Please check the flag --http-port ! NOTE ! - this guide is relevant for non-cloud managed Sisense deployments i.e. installed with Sisense Kubernetes (RKE). After upgrading Sisense to version L2024.1 you might face the following error in ingress-nginx-controller pod’s logs (the default namespace): main.go:64] port 80 is already in use. Please check the flag --http-port Such an issue might be the result of incompatibility between the  ingress-Nginx release version that was updated in Sisense L2024.1 and the Kubernetes version in case it is lower than v1.26. In case Sisense L2024.1 was freshly installed on the non-cloud instance (i.e. with Sisense RKE) as a fresh deployment (and was not upgraded from the previous version) this issue should not reveal since L2024.1 package already comes with v1.26 Kubernetes by default. However, if Sisense was upgraded to L2024.1 or it was deployed/installed on Kubernetes lower than v1.26 there will be an incompatibility between the  ingress-Nginx release implemented in L2024.1 ( 4.10.0 ). To resolve the issue it is necessary to re-run the Sisense upgrade with the following parameters in the configuration yaml file: update: true update_k8s_version: true In case you are still facing the same issue after that, please open a ticket for Sisense Support. This article provides a brief explanation regarding possible Nginx<->Kubernetes compatibility issues in Sisense L2024.1. The article also provides the steps to resolve the issue described. Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this please let us know.

      Dmytro Popov
      Dmytro PopovPosted 1 year ago
      0
               
      • Sisense AdministrationChevronRightIcon

      Verifying Sisense Installation Completion - Analyzing Migration Pod Messages

                               

      Title: Verifying Sisense Installation Completion - Analyzing Migration Pod Messages Summary This article provides basic understanding of how to perform initial verification of installation/upgrade process. Specifically, it covers the flow related to the "migration" pod and the "provisioner" pod, and provides steps to analyze if installation/upgrade process was successful. Main Content Step-by-Step Instructions to verify and confirm installation/upgrade is completed 1. Verify Upgrade Completion: Ensure that the upgrade process has completed successfully by checking the status of all Sisense pods. Use the following command to describe the pods in the sisense (default namespace for Sisense; in case another namespace is used for the installation, replace sisense with the actual one) namespace: kubectl -n sisense describe pod helm ls -A Verify that all Sisense containers are using the desired major version and that the provisioner pod is in the "Completed" state. Verify that “ sisense-<desired_version> ” Helm chart is in “deployed” state NOTE: If case of initial installation, some pods might be in Init status - this is expected behavior due to the need of license activation. Check if Sisense can be accessible by visiting <your_Sisense_URL>/app/account#/login page 2. Check Migration Pod Possible Errors: Review the output of the migration pod to identify any errors. Note that the migration process includes a set of verifications. If a critical issue is detected, the process will crash and exit with code ‘1’. However, if the process exits with code '0', it indicates a successful run despite any informational errors. kubectl -n sisense logs $(kubectl -n sisense get pod -l app.kubernetes.io/name=migration --no-headers | head -n 1 | awk '{print $1}') Common errors may include, for example, verification issues with cleaning dashboard subscriptions, where an argument might be null instead of an expected integer. These errors are informational and do not indicate a migration failure. 3. Understanding Provisioner Process: The provisioner process may complete faster than usual for newer Sisense releases (such as L2024.3 and higher) due to backend optimizations. If the provisioner pod freezes or ends without completion, please contact Sisense Support Team. If Provisioner pod is in “Completed” status it usually indicates to successful installation/upgrade completion Related Content: Docs:  https://docs.sisense.com/main/SisenseLinux/installing-sisense-on-linux.htm Academy:  https://academy.sisense.com/linux-essentials-for-ms  

      Dmytro Popov
      Dmytro PopovPosted 1 year ago
      0
               
      • TroubleshootingChevronRightIcon

      Error on installation "cp: cannot create regular file '/usr/local/bin/kubectl': Text file busy"

                                       

      The error "cp: cannot create regular file '/usr/local/bin/kubectl': Text file busy" typically occurs when multiple upgrade processes are running simultaneously, causing a conflict when trying to update the kubectl binary.     [2024-10-30 12:33:34] Getting binaries kubectl (v1.30.3) and helm (v3.12.3) [2024-10-30 12:33:34] Downloading them from the internet % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 138 100 138 0 0 1367 0 --:--:-- --:--:-- --:--:-- 1380 100 49.0M 100 49.0M 0 0 3478k 0 0:00:14 0:00:14 --:--:-- 3525k % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 15.2M 100 15.2M 0 0 3730k 0 0:00:04 0:00:04 --:--:-- 3731k linux-amd64/helm cp: cannot create regular file '/usr/local/bin/kubectl': Text file busy [2024-10-30 12:33:53] ** Error occurred during command sudo cp installer/05_post_infra/files/kubectl installer/05_post_infra/files/helm /usr/local/bin section ** [2024-10-30 12:33:53] ** Exiting Installation ... **   For example, in one case, the error occurred because multiple upgrades were happening on the same environment simultaneously (the same bastion for several cloud environments), which led to the Kubectl binary being in use by another upgrade process. The recommended solution is to check if any process is using Kubectl or Helm before proceeding with the upgrade. Watching an upgrade with "kubectl ... -w" command can cause this issue also. To prevent this error, it is advisable to: Ensure that no other upgrade or deployment processes are running in parallel. Use commands like lsof -t $(which kubectl) and lsof -t $(which helm) to check if these binaries are in use. If any command returns a PID, print out the process details using ps -ef | grep <pid number> and fail the pipeline if necessary. By following these steps, you can avoid the "Text file busy" error and ensure a smooth upgrade process. Related Content: https://academy.sisense.com/sisense-administration https://docs.sisense.com/main/SisenseLinux/upgrading-sisense.htm  

      Oleg Valynkin
      Oleg ValynkinPosted 1 year ago
      0
               
      • Sisense AdministrationChevronRightIcon

      Sisense Licensing issues

                               

      Sisense Licensing issues Sisense Licensing issues If you are having issues with your Sisense Environment and need help with the number of users on your license, there are a few steps you can take to ensure your license is current and up to date within your environment. Possible Issues: Issue : Your license details were changed, but changes are not reflected in your environment: For the changes to your license to be applied on your Sisense instance, please follow the instructions below on all the servers that utilize the email address corresponding to the updated license. For Windows version: On each of your Sisense servers please do the following: Within the Windows menu, search for Sisense Activation, then right-click 'Run as Administrator   Take note of the email address your account is set up under (you will need the password when you log back in) Sign out of your Sisense account Close Sisense Activation Stop and Restart the Sisense.Oxygen service by doing the following Open the Control Panel - Administrative Tools - Services  Locate the Sisense.Oxygen service and right-click and select Stop to stop it   Then, right-click and select Start to start it Then reopen and log back into Sisense Activation For Linux version: Within the Sisense web interface navigate to the Admin tab Navigate to the License Utilization page from the left panel Click on "Change License" Enter the license credentials and press "apply"     If this does not help, try to use the “Behind a Firewall?” option: Copy the Machine ID Go to https://my.sisense.com/ Press on “Generate Offline Key” and get the key using MID Copy and paste this key to Sisense to reset the License       Note, whenever we change the license owner's email the password is reset to the default password.   Issue: License not found To reset the license activation, please see this article and follow the steps to reset. Issue: "Your license has exceeded its user limit" When trying to migrate a Sisense environment from one machine to another, the installation might fail, returning the error message " Your license has exceeded its user limit":     As long as the number of active servers does not exceed the license permission, any other running servers should not be affected by them; however, please bear in mind that to prevent license issues, it is recommended to first perform a complete uninstallation on the previous server before installing Sisense on a new server. The following steps will reset the number of installations performed by a user. Log in to your account at https://my.sisense.com/ Press on “RESET ACTIVATIONS”     3.  Once the Activations counter is set to 0, you should be able to install Sisense on a new machine.  In case of any technical issues with licenses feel free to contact Sisense Support , or create a Support Case . For questions relating to license expiration, email/package owner change, etc. feel free to contact your Account Manager directly instead.

      Ihor Buriak
      Ihor BuriakPosted 3 years ago • Last reply 2 years ago
      1
               
    • Blog banner
      • Add-ons & Plug-InsChevronRightIcon

      Debugging Server Side External Sisense Plugins using HTTP Requests

                                                                                       

      Debugging Server Side External Sisense Plugins using HTTP Requests Sisense external plugins are server-side Sisense plugins that run on the Sisense server itself, rather than in the client-side browser like standard non-external Sisense plugins. These external plugins are stored in the "external-plugins" folder within the Sisense server file structure and are written in standard JavaScript. While most Sisense plugins can be developed using client-side JavaScript, there are cases where server-side code is necessary. When developing or debugging existing external Sisense plugins, it can be helpful to monitor the status of plugin variables at various points in the code. This can aid in understanding the current behavior or diagnosing errors. One way to achieve this type of debugging is to send HTTP requests containing the current variable state from the Sisense server. These requests contain the current value of one or more variables at a specific point in the plugin code. The target for these requests can either be a self-hosted server or a cloud-hosted HTTP logging service, such as Webhook.site, which provides a custom URL for logging and viewing HTTP requests through a browser. Any standard JavaScript HTTP request library can be used. For example, Axios can be used to log the current state of a variable using code like this:     const debugHTTPRequestFunction = (variableToDebug) => { axios.post('https://webhook.site/your-Unique-Webhook-URL-or-any-server-with-viewable-logs', { data: [args] }) }     One common issue when sending  Sisense JS API objects such as the prism object, or a dashboard or widget object in the payload of a HTTP request, is that the object can be self-referential, making it challenging to convert to JSON in the usual manner. The following code can be used to remove circular references in JSON:     function refReplacer() { let m = new Map(), v = new Map(), init = null; return function (field, value) { let p = m.get(this) + (Array.isArray(this) ? `[${field}]` : '.' + field); let isComplex = value === Object(value) if (isComplex) m.set(value, p); let pp = v.get(value) || ''; let path = p.replace(/undefined\.\.?/, ''); let val = pp ? `#REF:${pp[0] == '[' ? '$' : '$.'}${pp}` : value; !init ? (init = value) : (val === init ? val = "#REF:$" : 0); if (!pp && isComplex) v.set(value, path); return val; } }     To convert the JSON form of an object with circular references removed back into the object's original state, you can use the following function:     function parseRefJSON(json) { let objToPath = new Map(); let pathToObj = new Map(); let o = JSON.parse(json); let traverse = (parent, field) => { let obj = parent; let path = '#REF:$'; if (field !== undefined) { obj = parent[field]; path = objToPath.get(parent) + (Array.isArray(parent) ? `[${field}]` : `${field?'.'+field:''}`); } objToPath.set(obj, path); pathToObj.set(path, obj); let ref = pathToObj.get(obj); if (ref) parent[field] = ref; for (let f in obj) if (obj === Object(obj)) traverse(obj, f); } traverse(o); return o; }     Below is an example of sending a variable with circular references removed:     const debugHTTPRequestFunction = (variableToDebug) => { axios.post('https://webhook.site/c25d8caa-4cc7-4876-b595-33625c449a45', { data: [JSON.parse(JSON.stringify(args, refReplacer())) ] }) }     You can define this function once and use it in multiple parts of your code for debugging. Another example, incorporating the functions mentioned above, is shown below, where jQuery Ajax functionality is used, and circular references to a Sisense dashboard variable are removed:     let debugVariable = [JSON.parse(JSON.stringify(prism.activeDashboard, refReplacer()))] $.ajax({ type: "POST", url: "https://webhook.site/your-Unique-Webhook-URL-or-any-server-with-viewable-logs", crossDomain: true, data: JSON.stringify({ debugVariable: debugVariable }), success: function (data) { }, error: function (err) { } });       Comment your experience with this, we'd love to start this discussion! 

      Jeremy Friedel
      Jeremy FriedelPosted 2 years ago
      0
               
      • How-Tos & FAQsChevronRightIcon

      Setting up Docker Registry for Sisense Offline Installation

                                                               

      An offline, or air-gapped, Sisense environment provides higher security than online, connected environments. As the offline environment has no outside communication, the only method to install Sisense in this environment is by using removable media, such as USB drives. The system must have the following in place to complete an offline installation: A Bastion host with Docker installed (Recommended) A secured Docker registry that is accessible to the offline environment The Registry is a stateless, highly scalable server side application that stores and lets you distribute Docker images. In case of Sisense offline installation Docker Registry is used to distribute the Sisense images within an isolated network. Next article provides steps on how to install and configure the Docker registry. Configuring Docker engine  Install Docker to your server: a. In case if Docker Registry is also isolated as a future Sisense instance then it is necessary to download all required packages to bastion(or other machine that has Internet connection) and transfer them to a Docker Registry instance: wget https://download.docker.com/linux/ubuntu/dists/focal/pool/stable/amd64/docker-ce_20.10.24~3-0~ubuntu-focal_amd64.deb wget https://download.docker.com/linux/ubuntu/dists/focal/pool/stable/amd64/containerd.io_1.6.9-1_amd64.deb wget https://download.docker.com/linux/ubuntu/dists/focal/pool/stable/amd64/docker-ce-cli_20.10.24~3-0~ubuntu-focal_amd64.deb In case when you are installing Docker registry on the same instance with a Sisense, please note that Sisense currently supports only specific Docker versions: 1.13.x 17.03. x 17.06.x 17.09.x 18.06.x 18.09.x 19.03.x 20.10.× Install required packages: sudo dpkg -i ./docker-ce-cli_20.10.24~3-0~ubuntu-focal_amd64.deb sudo dpkg -i ./containerd.io_1.6.9-1_amd64.deb sudo dpkg -i ./docker-ce_20.10.24~3-0~ubuntu-focal_amd64.deb Start and enable docker and containerd services: sudo systemctl enable containerd sudo systemctl enable docker sudo systemctl start containerd sudo systemctl start docker b. If you are configuring Docker Registry on the machine which has internet connection, then it is possible to install docker in next way: Add Docker’s official GPG key: sudo install -m 0755 -d /etc/apt/keyrings   curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg   sudo chmod a+r /etc/apt/keyrings/docker.gpg Set up the repository: echo \    "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \    "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \    sudo tee /etc/apt/sources.list.d/docker.list > /dev/null Update the apt packet index and install latest docker: sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin To install a specific version:  # List the available versions: apt-cache madison docker-ce | awk '{ print $3 }' #example output:  5:23.0.2-1~ubuntu.20.04~focal 5:23.0.1-1~ubuntu.20.04~focal 5:23.0.0-1~ubuntu.20.04~focal 5:20.10.24~3-0~ubuntu-focal 5:20.10.23~3-0~ubuntu-focal 5:20.10.22~3-0~ubuntu-focal 5:20.10.21~3-0~ubuntu-focal #Install Docker with 5:20.10.21~3-0~ubuntu-focal: sudo apt-get install docker-ce = 5:20.10.21~3-0~ubuntu-focal  docker-ce-cli = 5:20.10.21~3-0~ubuntu-focal  containerd.io docker-buildx-plugin docker-compose-plugin     Verify installation by running a hello-world container: sudo docker run hello-world 2. [This step could be skipped in case if Docker Registry instance is supposed to be installed on non-isolated environment] Adding essential images to your registry: a. Pull essential images on the internet-connected machine: sudo docker pull registry:2.7.0 sudo docker pull httpd:2 b. Export basic registry images from the machine, that has internet connectivity: sudo docker save -o ./registry.tar registry:2.7.0 sudo docker save -o ./httpd.tar httpd:2 c. Transfer the images to the air-gapped machine with the tool of your choice - it could be an USB Flash drive for example d. Load images into the air-gapped server docker: sudo docker load -i ./httpd.tar sudo docker load -i ./registry.tar e. Verify the newly imported images: sudo docker images   REPOSITORY   TAG       IMAGE ID       CREATED         SIZE registry     2.7.0         8db46f9d7550   2 weeks ago     24.2MB httpd         2         73c10eb9266e   3 months ago   145MB Now the docker environment is installed and configured. Configuring Docker Registry As the first step we need to create directories which would be used by Docker Registry container. In this example we will use /var/registry: mkdir /var/registry mkdir /var/registry/auth mkdir /var/registry/certs First directory will be used to host the docker images, /var/registry/auth is supposed to be used for authentication files (which we will generate in the next step) and the last directory will be used for SSL certificates.  2. Now we are going to generate a htpasswd file which will contain authentication information for Docker registry. In this example we are using htpasswd as the name of the file and admin as the login. The tool which is generates this file is also called htpasswd: htpasswd -cB htpasswd admin And copy generated file to /var/registry/auth directory: cp htpasswd /var/registry/auth 3. In case if there are no any certificates prepared for docker registry, it’s possible to create a self-signed certificate: a. Generate a private key openssl genrsa 1024 > domain.key b. Create a san.cnf file with the following content: [req] default_bits   = 4096 distinguished_name = req_distinguished_name req_extensions = req_ext x509_extensions = v3_req prompt = no [req_distinguished_name] countryName = US stateOrProvinceName = N/A localityName = N/A organizationName = Self-signed certificate commonName = 120.0.0.1: Self-signed certificate [req_ext] subjectAltName = @alt_names [v3_req] subjectAltName = @alt_names [alt_names] IP.1 = 10.50.60.6 IP.1 here is the example. Please replace it with address of your Docker instance  c. Generate the key with: openssl req -new -x509 -nodes -sha1 -days 365 -key domain.key -out domain.crt -config san.cnf d. Copy generated files to /var/registry/certs directory: cp domain.ket /var/registry/certs cp domain.crt /var/registry/certs 4.  Time to start your docker registry. It could be done with the next command: docker run -d \   -p 5000:5000 \   --restart=always \   --name registry \   -v /var/registry/auth:/auth \   -e "REGISTRY_AUTH=htpasswd" \   -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \   -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \   -v /var/registry /certs:/certs \   -v /var/registry:/var/lib/registry \   -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \   -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \ registry:2.7.0 With the -v flags we are mounting host directories inside a container. With -e flags we are configuring certificates and auth files. -p flag is configuring a port on which Docker Registry is supposed to work outside the container. Please note - All directories in this article are examples and could be changed according your needs and requirements. If all steps were performed correctly, the Docker Registry should run without any issues and ready to be used with a Sisense offline installation. Sisense offline installation is described in our documentation here. Additional information  To be able to use docker registry with a self-signed certificate, it’s required to place your certificate file into the particular directory on the client machine, that consists of host name (or IP) and host port. Here is an example: /etc/docker/certs.d/10.10.10.10:5000/domain.crt Test your repository with the “docker login” : docker login 10.10.10.10 In both cases 10.10.10.10 is just an example address and should be replaced with the actual one. Please let us know if you have any questions or suggestions regarding this article - we are happy to discuss it below. 

      Vlad Solodkyi
      Vlad SolodkyiPosted 3 years ago • Last reply 2 years ago
      3