Ninox Private Cloud on Premise - Installation

System Requirements

Supported Operating Systems

  • Windows Server 2008 or later

Minimum Hardware Requirements:

  • 4 GB RAM
  • 2 vCores
  • 100 MBit network connection
  • 120 MB free disk space for the installation files
  • 10 GB free disk space for application data (actual requirement depends heavily on the use case, a scalable store solution is recommended)

Environment dependencies:

  • DNS name
  • Free port (e.g. 80 or 443, other ports can be configured as well)
  • HTTP(S) connectivity client => server
  • SSL certificate (#PKCS12 / .pfx) with or without private key passphrase (note: passphrase will be stored as plain text in the configuration file)
  • SMTP server with or without authentication

Recommendations

  • Ninox data files should be stored on SSD storage
  • Implement a backup strategy, we recommend to have at least two layers of backup
  • VM snapshots
  • File system based incremental backups of the data directory
  • Implement a fail-over strategy

Network Configuration

Ninox client/server communication is based on HTTP(S).

There are multiple ways to configure a Ninox installation, however the following properties must be given:

  • Clients must be able to connect to the Ninox server by HTTPS via TCP/IP.
  • A DNS name for the Ninox server (or the first component in the configuration that terminates the client connection) that reliably resolves to the server's IP.
  • Static IP addresses are highly encouraged, DynDNS is not recommended.
  • If clients connect from the Internet and intranet, they need to use the same address / DNS name.

A) Simple setup

Client —HTTPS—> Server

The basic configuration requires, that Ninox Server exposes a port for HTTP communication on the internet or private network.

B) Forward Proxy setup

Client —HTTPS—> Forward Proxy —HTTPS—> Server

This setup is recommended for installing a Ninox server in a corporate intranet.

C) DMZ setup

Client —HTTPS—> Reverse Proxy —HTTP—>Server

In a DMZ environment, a reverse proxy will terminate any client-side communication. This is the recommended configuration for environments that already implemented a DMZ. There are multiple advantages:
Centralized certificate management on the reverse proxy
Reverse proxy can act as a security component with traffic inspection

Requirements for reverse proxy:

  • Allow all HTTP methods (GET, PUT, POST, DELETE, OPTIONS, HEAD)
  • TCP timeouts must be higher than 60 secs
  • No path rewriting rules, Ninox cannot be mounted on a sub-path
  • Ninox may use heavily parallel TCP connections. Make sure that the reverse proxy is capable of handling those (calculate at least 2 concurrent connections per concurrent client)


Configuration File

Edit the server-config.json file in the installation directory.

Remarks: The file must be a UTF-8 encoded JSON format compliant file. It must not involve proprietary UTF-8 encoding headers. On Windows, please don't use Notepad to edit this file, instead use Notepad++ or SublimeText to edit the file.

The file provides the following configuration options:

{
"data": "data",
"ssl": false,
"host": "localhost",
"port": 8080,
"bindPort": 8080,
"bindInterface": "0.0.0.0",
"redirectPort": 9090,
"workers": 2,
"emailHost": "",
"emailPort": null,
"emailSecure": true,
"emailUser": "",
"emailPassword": "",
"emailFrom": "",
"apiAuthorization": "Bearer 123456789123456789",
"die": 60000
}

data: Absolute path (or relative from the installation path) of the data directory.

ssl: Either false to not use SSL or

{
"passphrase": "passphrase"
"key": "private.key"
"ca": "ca.pem"
"cert": "cert.pem"
}

passphrase: Passphrase of the encrypted key

key: Path of the key file

ca: Path of the CA certificate (if not included in the certificate file)

cert: PEM encoded certificate (may include chain)

host: The publicly visible domain name

port: The publicly visible port

bindPort: The local port, the HTTP server should bind to (usually the same as port)

bindInterface: The local network interface, the HTTP server should bind to (use "0.0.0.0" to make available on all interfaces.

redirectPort: If set and SSL is activated, the server will start a secondary HTTP server on that port which redirects any request to the SSL port.

workers: the number of HTTP worker processes, at least one, should not exceed the number of available cores. 4 should be sufficient even for major setups.

emailHost: The host of the outgoing SMTP server

emailPort: The port of the outgoing SMTP server

emailSecure: Use SSL

emailUser: SMTP authentication user

emailPassword: SMTP authentication password

emailFrom: The sender's address, e.g. ninox@mycompany.com

apiAuthorization: An optional authorization method for Ninox API calls. The value will be compared to the HTTP Authorization header.

die: The number of milliseconds, a Ninox team will be kept alive after the latest request has ended. Should be at least 60000.

Certificates

Though not required, it's encouraged to secure Ninox client/server communication with SSL. This requires to deploy a SSL certificate with the server.
Ninox supports two types of certificate formats:

PFX / #PKCS12

Configuration:

"ssl": {
"pfx": "certificate.pfx",
"passphrase": "secret"
}

PEM

Configuration:

"ssl": {
"ca": "ca-certificates.cer",
"cert": "certificate.cer",
"key": "private.key",
"passphrase": "secret"
}