Configuration Files
This section describes configuration files that ZoneMinder uses beyond the various Web UI options.
System Path Configurations
At one point of time, ZoneMinder stored various system path configurations under the Web UI (Options->Paths). This was removed a few versions ago and now resides in a configuration file. The motivation for this change can be read in this discussion.
Typically, path configurations now reside in /etc/zm.
Here is an example of the file hierarchy:
/etc/zm
├── conf.d
│ ├── 01-system-paths.conf
│ ├── 02-multiserver.conf
| ├── 03-custom.conf #optional
│ └── README
├── objectconfig.ini # optional
├── zm.conf
└── zmeventnotification.ini #optional
The roles of the files are as follows:
zm.confcontains various base configuration entries. You should not edit this file as it may be overwritten on an upgrade.zmeventnotification.iniis only present if you have installed the ZoneMinder Event Notification Server.objectconfig.iniis only present if you have installed the machine learning hooks for the Event Notification Server.conf.dcontains additional configuration items as follows:01-system-paths.confcontains all the paths that were once part ofOptions->Pathsin the Web UI. You should not edit this file as it may be overwritten on an upgrade02-multiserver.conffile consists of custom variables if you are deploying ZoneMinder in a multi-server configuration (see Multi-Server Install)03-custom.confis an custom config file that I created to override specific variables in the path files. This is the recommended way to customize entries. Anything that you want to change should be in a new file insideconf.d. Note that ZoneMinder will sort all the files alphabetically and run their contents in ascending order. So it doesn’t really matter what you name them, as long as you make sure your changes are not overwritten by another file in the sorting sequence. It is therefore good practice to prefix your file names bynn-wherennis a monotonically increasing numerical sequence01-02-03-and so forth, so you know the order they will be processed.
Timezone Configuration
Earlier versions of ZoneMinder relied on php.ini to set Date/Time Zone. This is no longer the case. You can (and must) set the Timezone via the Web UI, starting ZoneMinder version 1.34. See here.
Database Specific Configuration
Todo
do we really need to have this section? Not sure if its generic and not specific to ZM
While the ZoneMinder specific database config entries reside in /etc/zm/zm.conf and related customizations discussed above, general database configuration items can be tweaked in /etc/mysql (or whichever path your DB server is installed)
ZoneMinder finds its database using the following zm.conf settings. The
defaults match what the standard packages install, so most users never need to
change them; a remote database or custom credentials is the usual reason to.
Setting |
Default |
Description |
|---|---|---|
|
|
Database server type. |
|
|
Hostname or IP of the database server. A port can be appended as
|
|
|
Name of the ZoneMinder database. |
|
|
Database user ZoneMinder connects as. |
|
|
Password for that database user. |
As with the SSL settings below, override these in a conf.d file rather than
editing zm.conf directly, so your changes survive an upgrade.
Connecting to the Database over SSL/TLS
ZoneMinder can connect to its database over an encrypted SSL/TLS connection, which is useful when the database runs on a separate host. The connection is controlled by the following settings:
Setting |
Description |
|---|---|
|
Path to the CA certificate that signed the database server’s certificate. Setting this is what enables SSL; leave it empty for an unencrypted connection. |
|
Path to the client private key, for mutual TLS where the server also authenticates the client. |
|
Path to the client certificate, for mutual TLS. |
|
Whether to verify the server’s certificate. Defaults to |
These settings apply to every ZoneMinder component that talks to the database: the C++ daemons, the PHP web interface, the CakePHP API and the Perl scripts.
Although these entries exist in /etc/zm/zm.conf, that file may be overwritten
on an upgrade, so put your values in a conf.d override file instead. For
example, /etc/zm/conf.d/04-database-ssl.conf:
ZM_DB_SSL_CA_CERT=/etc/zm/ssl/ca.pem
ZM_DB_SSL_CLIENT_KEY=/etc/zm/ssl/client-key.pem
ZM_DB_SSL_CLIENT_CERT=/etc/zm/ssl/client-cert.pem
Note
ZM_DB_SSL_VERIFY_SERVER_CERT only has an effect when ZM_DB_SSL_CA_CERT
is set, and applies consistently across the C++ daemons, the PHP web
interface, the API and the Perl scripts. Verification includes a hostname
check, so the server certificate’s CN/SAN must match the value of
ZM_DB_HOST. A common gotcha: if ZM_DB_HOST is an IP address but the
certificate was issued for a hostname, verification fails — connect by the
hostname the certificate was issued for, add that IP to the certificate’s
SAN, or set ZM_DB_SSL_VERIFY_SERVER_CERT=0. Likewise a self-signed
certificate will fail verification; set the option to 0 to allow it.
Disabling verification means the server’s identity is no longer checked, so
only do this on a trusted network.
Leaving the value empty (rather than 1 or 0) leaves the database
client library’s own default in place. Fresh installs default to 1;
an empty value is mainly relevant to installs upgraded from a version that
predates this option, whose connection behaviour is then unchanged until the
value is set explicitly.