dbschema/dbschema-license-server repository overview

⁠Introduction

This is the official docker image for DbSchema⁠ license server. This image can be used to easily run the license server.

⁠Quick info

Please report any issues related to this image at https://dbschema.com/support.html⁠

⁠Supported tags

• 10.5.0, latest
• 10.4.0
• 10.0.3
• 9.9.3
• 9.9.0
• 9.8.3
• 9.7.3

⁠What is DbSchema?

DbSchema⁠ is the ultimate database design and management tool:

• connect to a wide range of databases
• visually design the database schema
• generate documentation
• use multi-level master-detail trees
• build queries visually
• generate migration scripts
• ... and much more

⁠How to run from the command-line

Run this command:

docker container run \
    --rm \
    --volume "/path/to/license-file.txt:/dbschema/license.txt:ro" \
    --publish 8080:8080 \
    dbschema/dbschema-license-server:10.5.0

This will:

• mount the floating license file located on the host computer at /path/to/license-file.txt to the path inside the container at /dbschema/license.txt. The ro (read-only) tells docker that the container is not allowed to modify the file.
• expose the port 8080, so that the server is reachable from outside the container

⁠How to run from Docker Compose

You can also use this image from Docker Compose, like this:

services:

  dbschema-license-server:
    image: dbschema/dbschema-license-server:10.5.0
    volumes:
      - "./DbSchemaLicense.txt:/dbschema/license.txt:ro"
    ports:
      - "8080:8080"

⁠Proxy and TLS environment variables

The license is read from the mounted file and requires no network access. While the server runs, however, dbschema.com can be contacted periodically to check whether a renewed license has been issued. Where the container has no direct route out, or where a TLS-inspecting proxy is interposed, that connection is configured through the variables below.

They are read once, when the container starts, so a change takes effect only on the next start. Either case is accepted (https_proxy or HTTPS_PROXY); where both are set with different values, the lower-case one is used and a warning is logged. A value that cannot be honored stops the container, with a message naming the variable.

⁠Proxy

The first of the three that is set is used. A single proxy is applied to every scheme (i.e. DbSchema does not support different proxies per HTTP/HTTPS), so where two hold different values the higher-ranked one is used and the disagreement is logged. ftp_proxy and rsync_proxy are ignored.

Value format: [scheme://][user:password@]host[:port]

A password may hold an @ or a : unencoded. A /, ? or # must be percent-encoded, as must a : within the user name and any % that two hexadecimal digits follow — p%2Fss for p/ss, 100%25 for 100%. A + is read literally, never as a space. Credentials supplied this way are visible in docker inspect and in /proc/<pid>/environ.

no_proxy entries are separated by commas or whitespace, and are matched case-insensitively:

An entry in none of these forms is reported in the log and skipped; the remainder of the list still applies.

⁠TLS certificates

A TLS-inspecting proxy presents a certificate of its own, which has to be trusted or every HTTPS connection fails.

The certificates they name are added to the authorities already trusted and never replace them, so ordinary HTTPS connections are unaffected.

A file or directory that is named but cannot be read, cannot be parsed, or holds no certificate at all stops the container.

Certificate verification cannot be disabled by any variable. Where a server's certificate is not trusted, the authority that issued it is to be named in SSL_CERT_FILE or SSL_CERT_DIR.

⁠Example

services:

  dbschema-license-server:
    image: dbschema/dbschema-license-server:10.5.0
    volumes:
      - "./DbSchemaLicense.txt:/dbschema/license.txt:ro"
      - "./corporate-ca.pem:/etc/ssl/corporate-ca.pem:ro"
    ports:
      - "8080:8080"
    environment:
      HTTPS_PROXY: "http://alice:[email protected]:3128"
      NO_PROXY: "localhost,127.0.0.1,.corp"
      SSL_CERT_FILE: "/etc/ssl/corporate-ca.pem"

⁠Verifying the configuration

The resolved proxy and the trusted certificate authorities are written to the container log at startup, with any password masked, and can be read with docker logs <container>. A single URL can be tested through the same settings by overriding the entry point:

docker container run --rm -it \
    --env HTTPS_PROXY="http://proxy.corp:3128" \
    --env SSL_CERT_FILE="/etc/ssl/corporate-ca.pem" \
    --volume "./corporate-ca.pem:/etc/ssl/corporate-ca.pem:ro" \
    --entrypoint /home/ubuntu/DbSchema/DbSchemaCLI \
    dbschema/dbschema-license-server:10.5.0

At the resulting prompt, check network https://example.com prints the proxy and trust in force, performs the request, and on failure reports the cause — including the certificate chain presented by an untrusted server.