Use 10Duke Scale Local License Server in Test Mode

The purpose of the 10Duke Scale Local License Server is to enable license management and license consumption in your customer’s private network.

The Local License Server is a server application that provides the licensing service to licensed applications over an HTTP connection.

See how to sign up as a 10Duke Scale customer.

Features and functions

The Local License Server supports licensing using license keys in enforced consumption mode. The main license record resides in the 10Duke Scale service.

Licenses with enforced quantity in 10Duke Scale can be checked out (transferred) to a Local License Server. In practice, 10Duke Scale generates a license token that specifies the quantity that was checked out, and this token can be transferred to the Local License Server and used by end users to consume the license.

For example, you check out 1 seat from the license at a time, which means a license token always allows use of 1 seat. Or, you can check out a certain amount of use count or use time, in which case the license token allows consuming the license for that amount.

When the Local License Server is used in online mode, the license checkout is done from the Local License Server administration UI. In an offline use case, the checkout is done in the 10Duke Scale UI console, and the license tokens are transferred to the Local License Server as files.

Read more about license consumption in 10Duke Scale and how licenses are checked out:

Limitations

Current limitations:

  • Identity-based licensing is only available in the online 10Duke Scale service.

  • Metered licenses can only be used with the online 10Duke Scale service.

  • The client application must send the same client application claims throughout the entire license consumption flow. The exactly same claims and their values that were originally used in the license checkout must also appear in heartbeat calls and the release call.

System requirements

The tested Docker and Docker Compose versions:

  • Docker major version 24 and newer

  • Docker Compose version 2.23.* and newer

Note: The Docker and Docker Compose versions must be aligned. Read more about Docker at Docker Engine and Docker Compose .

10Duke tests the Local License Server and the Docker-based setup using Fedora Linux 40 and Mac OS.

Required disk space

  • Reserve base disk space for Docker and three images: an Nginx image, a PostgreSQL image, and the Local License Server application image. For example, on a Fedora Linux system, these three images require approximately 2 GB of disk space.

  • Reserve 1 MB of disk space per 10 licenses.

Note: In production mode, the volumes configured for components in the Docker Compose stack must be persistent. Loss of storage will void all licenses and require re-activating the Local License Server. Running the Local License Server in test mode doesn’t require persistent volumes.

Required CPU

A reference has not yet been measured. The required CPU capacity is estimated to be modest.

Required memory

A reference has not yet been measured. The required memory capacity is estimated to be modest.

Delivery and installation of Local License Server

10Duke provides you (the vendor) with a Local License Server as an archive (such as a zip or tar file). You can modify the applicable configuration before providing the archive to your customers.

The archive contains:

  • The Local License Server executable, which is a Linux executable file.

  • A Docker Compose file, which configures the runtime platform and dependencies required by the Local License Server.

  • Configuration files for the Local License Server.

  • Installation and activation instructions (white-label documentation).

Installing the Local License Server is as simple as extracting the archive to a location chosen by the administrator responsible for the installation.

Activation of Local License Server

The Local License Server must be activated before it can be used for production use. The activation can be done either in online or offline mode.

Online activation is the recommended approach. Use offline activation when it’s not possible to activate the Local License Server using an internet connection.

Online activation

The following flow illustrates the activities and responsibilities in online activation for the end customer, the vendor, and 10Duke.

Local License Server online activation

The following UI wireframes illustrate how the end customer’s administrator activates the Local License Server in an online use case:

Local License Server steps in online activation

Offline activation

The following flow illustrates the activities and responsibilities in offline activation for the end customer, the vendor, and 10Duke.

Local License Server offline activation

The following UI wireframes illustrate how the end customer’s administrator activates the Local License Server in an offline use case:

Local License Server steps in offline activation

Testing your licensed applications

Before delivering the Local License Server to your customers, you can test applications using the Local License Server test mode.

Running the Local License Server in test mode

The specification for running the Local License Server using a Docker Compose file.

The archive provided by 10Duke contains a default Docker Compose file implementation. The file is called docker-compose.yaml and is located in the root of the archive.

Configuration for the Local License Server is given by adding a file called license-server.conf into the container path /opt/tenduke/config/license-server.conf.

Test mode start and stop commands:

  • To start the stack in test mode:

    docker compose up --build

  • To stop the stack in test mode:

    docker compose down --volumes

Configuration of Local License Server for test mode

When the Local License Server is started and running without activation, it will operate in test mode. The test mode enables use of the Local License Server in, for example, CI pipelines where the licensed application is tested. Many limitations compared to production use will be applied.

The configuration objects always_succeed and always_fail are predefined options that define built-in behavior. For example, a product SuperCalculator inside the always_succeed object will yield a successful checkout for every request a client application makes using that product name.

In the event of duplicates in always_succeed and always_fail, the priority is on always_fail. A warning is logged if duplicates are found.

Configuration keys and reserved keywords

Keyword / configuration key Description
always_fail Configures products that yield license checkout failures.
always_succeed Configures products that yield license checkout success.
products Configures names of licensed products and defines product to feature mapping.
* (asterisk) Used to denote a wild card for product names. For example, when used in always_succeed for a product name, a request to check out a license will work for any product name.

Configuration examples

All checkouts succeed: minimal configuration:

{
    "always_succeed": {
        "products":[
            "*": [
                "feature-1",
                "feature-2"
            ]
        ]
    }
}

All named product checkouts succeed: minimal configuration:

{
    "always_succeed": {
        "products":{
            "ThreeDee": [
                "feature-1",
                "feature-2"
            ],
            "MagicPro": [
                "feature-1",
                "feature-2"
            ]
        },
        "errorCode":"noLicenseFound",
        "errorDescription":"No matching license was found"
    }
}

The always_succeed error response is used in the case that the caller attempts a checkout with a product name that is not listed.

All checkouts fail: minimal configuration:

{
    "always_fail": {
        "products":{
            "ThreeDee": [
                "feature-1"
            ]
        },
        "errorCode":"insufficientQuantity",
        "errorDescription":"No capacity left on license: fake (SEATS)"
    }
}

Full configuration example:

{
    "always_succeed": {
        "products": {
            "ThreeDee": [
                "feature-1",
                "feature-2"
            ],
        },
        "errorCode":"noLicenseFound",
        "errorDescription":"No matching license was found"
    },
    "always_fail": {
        "products": {
            "MagicPro" [
                "feature-1",
                "feature-2"
            ]
        },
        "errorCode": "insufficientQuantity",
        "errorDescription": "No capacity left on license: fake (SEATS)"
    }
}

Further information

10Duke Scale API documentation that applies to the Local License Server test mode: