Ninox Private Cloud on Premise - Installation
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)
- 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
- 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
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)
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:
"apiAuthorization": "Bearer 123456789123456789",
data: Absolute path (or relative from the installation path) of the data directory.
ssl: Either false to not use SSL or
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. firstname.lastname@example.org
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.
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