This document describes the `config.ini` directives. It's an INI file, parsed by [PHP's `parse_ini_file`](https://www.php.net/manual/function.parse-ini-file.php). Every setting is expected to be present.
## `[common]`
### `root-path`
Filesystem path to the directory where the root of the program is installed.
### `public_domains[]`
Allowed server names. Used to make the authentication tokens specific to the service.
This configuration section is used by both the registry (`reg`) and the public name server (`ns`).
### `knotc_path`
Filesystem path to the `knotc` binary.
### `kdig_path`
Filesystem path to the `kdig` binary. Used to authenticate resources possession using the DNS.
## `[reg]`
### `suffixes[]`
Lists the suffixes that the registry manages.
The key is the suffix (ending with a dot) and the value is its registration availability, which can be one of the following:
*`all`: every account can register
*`approved`: only approved accounts can register
*`none`: nobody can register
This impacts only new registrations, existing domains can always be managed by users if their suffix appears in the list.
### `suffixes_path`
Filesystem path to the registries directory. The full path to the registry zonefile is `suffixes_path` + `/` + suffixes (as defined in suffixes[]) + `zone`.
### `ttl`
The TTL of every DNS record created by users (i.e. NS, DS and glue records).
### `address`
Host where the Knot DNS server answers the registry values. Should be a secure (local) address, as answers are not authenticated.
(Used to check the transfer authentication records.)
## `[ns]`
### `knot_zones_path`
Filesystem path to the zones directory. The full path to created zonefiles will be `knot_zones_path/<zone-apex-domain>.zone`.
### `servers[]`
The first element is set as the primary server in the SOA.
All elements are listed in the interface so users can know what NS records to set in their zone.
### `kzonecheck_path`
Filesystem path to the `kzonecheck` binary. Used to check sent plaintext zonefiles.
Administrator email address published in every SOA record. Ends with a `.`, `@` is replaced by a `.`, an hypothetical `.` in the first part of the address is escaped using a `\` before, thus `contact.admin@servnest.example` becomes `contact\.admin.servnest.example.`
Filesystem path to the users files base directory. Files of a user are located inside `ht_path/<their-internal-user-id>/`
### `subpath_domain` and `subpath_path`
For the feature of sites in subpathes of a single domain:
`subpath_domain` is the said shared domain, displayed in the interface
`subpath_path` is the filesystem path to the directory whose address is the HTTP root of `subpath_domain`
`https://<subpath_domain>/example/` maps to `<subpath_path>/example/`
### `subdomain_domain` and `subdomain_path`
For the feature of sites in subdomains of a root domain:
(The root domain must have a wildcard TLS certificate and wildcard AAAA and A records.)
`subdomain_domain` is the root domain, displayed in the interface
`subdomain_path` is the filesystem path to the directory whose direct subdirectories are mapped to direct subdomains of `subdomain_domain`
`https://example.<subdomain_domain>/` maps to `<subdomain_path>/example/`
### `nginx_config_path`
Filesystem path to the directory that contains configuration files for dedicated sites.
The `http` block of nginx must contain something like `include <nginx_config_path>/*.conf;`
### `nginx_reload_cmd`
Command to execute through sudo to reload the nginx daemon.
### `tor_config_path`
Filesystem path to the directory containing Tor configuration for onion accesses. The full Tor configuration file path is `tor_config_path/<internal-user-id>/<site-dir-name>`
### `tor_keys_path`
Tor sets up keys inside the directory `tor_keys_path/<internal-user-id>/<site-dir-name>/`
### `tor_user`
Linux user as who runs the Tor daemon. Some commands are executed as this user through sudo.
### `tor_reload_cmd`
Command to execute through sudo to reload the Tor daemon.
### `sudo_path`
Filesystem path to the sudo binary.
### `certbot_path`
Filesystem path to the certbot binary. It is used through sudo to get a Let's Encrypt certificate.
Filesystem paths to the corresponding GNU coreutils binary (other implementations are not tested). (Their PHP counterpart can't be used as they need to act as another user through sudo.)
Filesystem path to the root directory that is served when a request hits `.well-known/acme-challenge` on port 80. Certbot places ACME authentication files here to get Let's Encrypt certificates through the HTTP-01 challenge.
Filesystem path to the unix socket created by nginx and listening for incoming Onion services connections. (Used in Tor and nginx configuration files when creating an Onion service.)