FAQ

Consult with your vendor to make sure that your graph database is installed on appropriate hardware and configured for better performances:

Cosmos DB: high-availability guide
Neo4j: sizing and hardware guide, clustering guide

Make sure that your graph database is secure:

Cosmos DB: security guide
Neo4j: security checklist

Keep in mind that Linkurious Enterprise can be used without Elasticsearch, see search options.

If you are using Linkurious Enterprise with Elasticsearch

Make sure your have the right hardware for Elasticsearch
See how to secure Elasticsearch

By default, SQLite is used for the user-data store. SQLite is not recommended for production environment: switch to MySQL/MariaDB/MSSQL instead.

Schedule regular backups of the user-data store:

Make sure your user-data-store database is secure

If you need high-availability, set up replication

MariaB: replication overview, setting up replication
MySQL: replication guide,
MSSQL: replication guide

Make sure Linkurious Enterprise runs under a service account
This service account should be the only user on the system to have read and write access to the linkurious/data directory
Enable authentication
If needed, configure external authentication
Enable HTTPS
- If needed, force users to use HTTPS (see forceHttps: true in Web Server configuration)
- If needed, add your custom Certificate Authority (CA)

Linkurious Enterprise can be set up with a backup instance to allow for continuity of service when the main server crashes.

For this setup:

both Linkurious Enterprise instances must have the same configuration
both Linkurious Enterprise instances must be connected to the same graph databases
both Linkurious Enterprise instances must be connected to the same search indexes
both Linkurious Enterprise instances must be connected to the same user-data store
if alerts are in use, they should be enabled only on the main instance (see how to disable alerts).

A reverse proxy is then configured to send requests to the backup server when the main server is down. If you are using nginx, this sample configuration can be used:

http {
    # define the "backend" upstream
    upstream backend {
        # main server
        server linkurious-main.example.com;

        # backup server
        server linkurious-backup.example.com backup;
    }

    # redirect all queries to the "backend" upsteam
    server {
        location / {
            proxy_pass http://backend;
        }
    }
}

See nginx documentation for more details.

Fault-tolerance diagram

The user-data store database (containing visualizations, saved queries, user, groups, etc) is stored in a SQL database.

By default, this database is an SQLite database (located at linkurious/data/database.sqlite). In production, the use of a MySQL/MariaDB/MSSQL database is recommended. These databases can be located on a remote server.

The default user-data store (SQLite) is not encrypted.

Encryption is available with the following vendors:

Yes, when using an external user-data store (e.g. MariaDB, MySQL or MSSQL), the SQLite files can be deleted.

The configuration file contains all configurable options, as well as the configuration options of all configured data sources (e.g. User-Data Store host/port/username/encrypted password; Graph Database URL/username/encrypted password; Index Search URL/username/encrypted password, etc). All passwords/secrets in the configuration file are encrypted before storage.

The configuration file, like the rest of the data folder, should be considered private and not be readable by anyone other than the Linkurious Enterprise service account.

All application secrets stored by Linkurious Enterprise (Graph Database credentials, User-Data Store credentials, Index Search credentials, SSL certificate passphrase, etc.) are encrypted using the AES-256-CTR algorithm.

User passwords are strongly hashed before being stored in the database. Passwords for LDAP and other external authentication solutions are not stored at all.

The audit trail files are generated in linkurious/data/audit-trail by default. This path can be set in the audit trail configuration.

The audit trail contains sensitive information and should be secured. It should be owned and readable only by the Linkurious Enterprise service account.

The data directory contains logs, configuration files, and, if enabled, audit trails. This information is sensitive, and the directory should be owned and readable only by the Linkurious Enterprise service account

A service account is an operating system user account with restricted privileges that is used only to run a specific service and own it data related to this service. Service accounts are not intended to be used by people, except for performing administrative operations. Access to service accounts is usually tightly controlled using privileged access management solutions.

Service accounts prevent other users and services from reading or writing to sensitive files in the directories that they own, and are themselves prevented from reading and writing to other parts of the file system where they are not owners.

We do not support Kerberos as of now (but we support many other third-party authentication services).

Linkurious Enterprise creates three types of logs:

Analytics (data/logs/analytics.log): Usage telemetry (GDPR safe, not sensitive information)
Technical logs (data/logs/linkurious.log and linkurious.exceptions.log): Server debugging logs (may contain graph queries).
Audit Trail (data/audit-trail/audit-trail.log): See audit trail log format details.

If your LDAP server supports secure LDAP, use the "ldaps://" protocol in your LDAP configuration.

If you need authentication and transport layer security for Elasticsearch:

Option A: Purchase this service from Elasticsearch
Option B: Put Elasticsearch behind a reverse proxy to transport layer security and authentication

To customize supported TLS ciphers, in the general configuration, set tlsCipherList in the server section. Here is an example, based on Mozilla's recommended cipher list:

{
  "tlsCipherList": "TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:!eNULL:!aNULL"
}

We are trying to keep the Linkurious Enterprise update process as simple as possible. However, sometimes configuration can require specific manual activities.

Before you upgrade to a new version of Linkurious Enterprise, consider browsing our public resources to verify whether there are specific instructions that applies to your configuration or activities you are planning.

If you have issues configuring a secure connection, temporarily tweaking the TLS settings may help troubleshooting the issue.

TLS certificate validation can be disabled by setting the environment variable NODE_TLS_REJECT_UNAUTHORIZED to 0. Note this should only be done for troubleshooting purpose as it makes TLS inherently insecure.

Some useful Node options can also be set:

--trace-tls: Prints TLS packet trace information in the manager logs.
--openssl-legacy-provider: Enable OpenSSL 3.0 legacy provider.
--tls-cipher-list=list: Specify an alternative default TLS cipher list (this can also be set in Linkurious Enterprise configuration file).

These settings can be set in the /data/manager/manager.json configuration file, in the env section of the Linkurious Server service. For instance, it may looks like this:

{
  "env": {
    "NODE_TLS_REJECT_UNAUTHORIZED": 0,
    "NODE_OPTIONS": "--max-old-space-size=4096 --trace-tls --openssl-legacy-provider --tls-cipher-list=DEFAULT@SECLEVEL=0"
  }
}

For Neo4j connections, certificate validation can be disabled by changing the URL scheme:

neo4j+s:// can be replaced by neo4j+ssc:// (where ssc means "self signed certificate", it disables certificate validation).
bolt+s:// can be replaced by bolt+ssc://.

For Active Directory, TLS debug settings can be set directly in the Linkurious Enterprise configuration file, see Active Directory configuration.

PEM (for Privacy-Enhanced Mail) is a file format for storing and sending cryptographic keys and certificates.

To verify if a certificate is PEM-encoded, open it with a text-editor, it should look something like this:

If you have a DER-encoded certificate (binary), it can be converted to PEM:

on Linux: openssl x509 -inform der -in certificate.cer -out certificate.pem
on Windows:
- double-click on the certificate to open it (if prompted to select a program, choose Crypto Shell Extensions)
- go to the details tab
- click Copy to file...
- click Next
- select Base-64 encoded X.509 (.CER) and click Next
- choose a path to save the file, click Next
- click Finish
- the exported certificate file (with '.CER' extension) is now in PEM format.

Most graph vendors support search strategies other than Elasticsearch. See details on our search options page.

Yes. See the geospatial configuration options for further details.

Yes, you can configure ArcGIS as the tile-server for geo-spatial mode. The ArcGIS documentation describes the API endpoints that is compatible with Linkurious Enterprise:

endpoint URL: http://<MapServer-url>/tile/{z}/{y}/{x}
please refer to the geospatial configuration options for further details.

For example:

MapServer URL: https://server.arcgisonline.com/ArcGIS/rest/services/World_Topo_Map/MapServer/
URL template: https://server.arcgisonline.com/ArcGIS/rest/services/World_Topo_Map/MapServer/tile/{z}/{y}/{x}

./linkurious/start.sh: start the server
./linkurious/stop.sh: stop the server
./linkurious/menu.sh: open the management console
./linkurious/menu.sh status: print the current status of the server
./linkurious/menu.sh install: install as a system-wide service (requires root)
./linkurious/menu.sh uninstall: remove from system-wide services (requires root)
./linkurious/menu.sh help: show advanced options

Depending on the configuration options specified, enabling the audit trail can have an impact on performance. See the audit trail documentation for details.

Previous Next

FAQ

Going to production

What should I do before going to production?

1. Ready your graph database for production

2. Ready Elasticsearch for production

3. Ready your user-data store for production

4. Ready Linkurious Enterprise itself for production

How can Fault tolerance be achieved?

Security

Where is the user-data store located?

Is the user-data store encrypted?

Is it possible to delete the SQLite user-data store when using an external database?

What kind of information is stored in the configuration file?

How are application secrets stored?

How are user credentials stored?

Where is the audit trail stored?

Does enabling the audit-trail require additional security measures?

How can the data directory be secured?

What is a service account and why should I use one?

Can Kerberos be used for single sign-on?

What do the log files contain?

How can the communication with an LDAP server be secured?

How can Elasticsearch be secured?

Can I customize the cryptographic ciphers used for TLS?

What should I do before updating Linkurious Enterprise to a new release?

Miscellaneous

How can I troubleshoot TLS connectivity issues?

What are PEM Certificates?

Can I use Linkurious Enterprise without Elasticsearch?

Can I use a custom tile server in geo-spatial mode?

Can I use ESRI ArcGIS for geo-spatial mode?

What are the command lines utilities to administrate Linkurious Enterprise?

Will enabling the audit trail impact performance?