Commit 9a8a26f8 authored by Daniel Salzman's avatar Daniel Salzman

doc: update config changes

parent 8f9e17cb
......@@ -351,7 +351,7 @@ acl:
\- id: STR
address: ADDR[/INT] | ADDR\-ADDR ...
key: key_id ...
action: transfer | notify | update | control ...
action: notify | transfer | update ...
deny: BOOL
.ft P
.fi
......@@ -385,8 +385,6 @@ Possible values:
\fBnotify\fP – Allow incoming notify
.IP \(bu 2
\fBupdate\fP – Allow zone updates
.IP \(bu 2
\fBcontrol\fP – Allow remote control
.UNINDENT
.sp
\fIDefault:\fP not set
......@@ -398,38 +396,23 @@ Deny if \fI\%address\fP, \fI\%key\fP and
\fIDefault:\fP off
.SH CONTROL SECTION
.sp
Configuration of the server remote control.
.sp
\fICaution:\fP The control protocol is not encrypted and is susceptible to replay
attacks in a short timeframe until message digest expires. For that reason,
it is recommended to use default UNIX socket.
Configuration of the server control interface.
.INDENT 0.0
.INDENT 3.5
.sp
.nf
.ft C
control:
listen: ADDR[@INT]
acl: acl_id ...
listen: STR
.ft P
.fi
.UNINDENT
.UNINDENT
.SS listen
.sp
A UNIX socket path or IP address where the server listens for remote control
commands. Optional port specification (default is 5533) can be appended to the
address using \fB@\fP separator.
A UNIX socket path where the server listens for remote control commands.
.sp
\fIDefault:\fP \fI\%rundir\fP/knot.sock
.SS acl
.sp
An ordered list of \fI\%references\fP to ACL rules allowing the remote
control.
.sp
\fICaution:\fP This option has no effect with UNIX socket.
.sp
\fIDefault:\fP not set
.SH REMOTE SECTION
.sp
Definitions of remote servers for outgoing connections (source of a zone
......
......@@ -11,12 +11,14 @@ Other than that, there are no differences and you can control both the same way.
The tool ``knotc`` is designed as a user front-end, making it easier to control running
server daemon. If you want to control the daemon directly, use ``SIGINT`` to quit
the process or ``SIGHUP`` to reload configuration.
the process or ``SIGHUP`` to reload the configuration.
If you pass neither configuration file (``-c`` parameter) nor configuration
database (``-C`` parameter), server will attempt to use the default configuration
file stored in ``SYSCONFDIR/knot/knot.conf`` (the path can be reconfigured with
``--with-configdir=path``).
database (``-C`` parameter), the server will first attempt to use the default
configuration database stored in ``LOCALSTATEDIR/lib/knot/confdb`` or the
default configuration file stored in ``SYSCONFDIR/knot/knot.conf``. Both the
default paths can be reconfigured with ``--with-storage=path`` or
``--with-configdir=path`` respectively.
Example of server start as a daemon::
......@@ -26,8 +28,8 @@ Example of server shutdown::
$ knotc -c knot.conf stop
For a complete list of actions refer to ``knotd -h`` and ``knotc -h``
or corresponding man pages.
For a complete list of actions refer to the program help (``-h`` parameter)
or to the corresponding manual page.
Also, the server needs to create :ref:`server_rundir` and :ref:`zone_storage`
directories in order to run properly.
......@@ -37,14 +39,18 @@ directories in order to run properly.
Configuration database
======================
In the case of a huge configuration file, the configuration can be preloaded
into the server's configuration database::
In the case of a huge configuration file, the configuration can be stored
in a binary database. Such a database can be simply initialized::
$ knotc -C db_path conf-import input.conf
$ knotc conf-init
Also the configuration database can be exported into a configuration file::
or preloaded from a file::
$ knotc -C db_path conf-export output.conf
$ knotc conf-import input.conf
Also the configuration database can be exported into a textual file::
$ knotc conf-export output.conf
*Caution:* The import and export commands access the configuration database
directly, without any interaction with the server. So it is strictly
......@@ -55,25 +61,22 @@ recommended to perform these operations when the server is not running.
Dynamic configuration
=====================
The configuration database can be accessed using the server remote control
The configuration database can be accessed using the server control interface
during the running server. To get the full power of the dynamic configuration,
the server must be started with a specified configuration database location::
$ knotd -C db_path
the server must be started with a specified configuration database location
or with the default database initialized. Otherwise all the changes to the
configuration will be temporary (until the server stop).
*Note:* The database can be :ref:`imported<Configuration database>` in advance.
Otherwise all the changes to the configuration are temporary (until the server
stop).
Most of the commands get item name and value parameters. An item is in the form
of ``section[identifier].item``. If the item is multivalued, more values
can be specified with a space separation.
Most of the commands get an item name and value parameters. The item name is
in the form of ``section[identifier].name``. If the item is multivalued,
more values can be specified with a space separation.
To get the list of configuration sections or to get the list of section items::
$ knotc conf-desc
$ knotc conf-desc server
$ knotc conf-list
$ knotc conf-list server
To get the whole configuration or to get the whole configuration section or
to get all section identifiers or to get a specific configuration item::
......@@ -102,8 +105,8 @@ section identifier or to add a value to all identified sections::
$ knotc conf-set zone[example.com]
$ knotc conf-set zone.slave slave2
*Note:* Also the include operation can be performed (the file location is
relative to the server binary!)::
*Note:* Also the include operation can be performed. A non-absolute file
location is relative to the server binary path (not to the control binary path)!::
$ knotc conf-set include /tmp/new_zones.conf
......@@ -155,21 +158,20 @@ immediately but after the :ref:`zone_zonefile-sync` period elapses.
Master mode
===========
If you just want to check the zone files before starting, you
can use the ``knotc checkzone`` action::
If you just want to check the zone files before starting, you can use::
$ knotc -c master.conf checkzone example.com
$ knotc zone-check example.com
For an approximate estimation of server's memory consumption, you can
use the ``knotc memstats`` action. This action prints the count of
resource records, percentage of signed records and finally estimation
of memory consumption for each zone, unless specified otherwise.
Please note that the estimated values may differ from the
For an approximate estimation of server's memory consumption, you can use::
$ knotc zone-memstats example.com
This action prints the count of resource records, percentage of signed
records and finally estimation of memory consumption for each zone, unless
specified otherwise. Please note that the estimated values may differ from the
actual consumption. Also, for slave servers with incoming transfers
enabled, be aware that the actual memory consumption might be double
or higher during transfers::
$ knotc -c master.conf memstats example.com
or higher during transfers.
.. _Controlling running daemon:
......@@ -179,19 +181,15 @@ Daemon controls
Knot DNS was designed to allow server reconfiguration on-the-fly
without interrupting its operation. Thus it is possible to change
both configuration and zone files and also add or remove zones without
restarting the server. This can be done with the ``knotc reload``
action::
restarting the server. This can be done with::
$ knotc -c master.conf reload
$ knotc reload
If you want to enable ixfr differences creation from changes you make to a
zone file, enable :ref:`zone_ixfr-from-differences` in the zone configuration
and reload your server as seen above. If *SOA*'s *serial* is not changed,
no differences will be created.
If you want to refresh the slave zones, you can do this with the
``knotc refresh`` action::
$ knotc -c slave.conf refresh
If you want to refresh the slave zones, you can do this with::
For the zone retransfer, there is also an additional command ``-f``.
$ knotc zone-refresh
......@@ -386,7 +386,7 @@ update, etc.).
- id: STR
address: ADDR[/INT] | ADDR-ADDR ...
key: key_id ...
action: transfer | notify | update | control ...
action: notify | transfer | update ...
deny: BOOL
.. _acl_id:
......@@ -429,7 +429,6 @@ Possible values:
- ``transfer`` – Allow zone transfer
- ``notify`` – Allow incoming notify
- ``update`` – Allow zone updates
- ``control`` – Allow remote control
*Default:* not set
......@@ -448,41 +447,22 @@ Deny if :ref:`address<acl_address>`, :ref:`key<acl_key>` and
Control section
===============
Configuration of the server remote control.
*Caution:* The control protocol is not encrypted and is susceptible to replay
attacks in a short timeframe until message digest expires. For that reason,
it is recommended to use default UNIX socket.
Configuration of the server control interface.
::
control:
listen: ADDR[@INT]
acl: acl_id ...
listen: STR
.. _control_listen:
listen
------
A UNIX socket path or IP address where the server listens for remote control
commands. Optional port specification (default is 5533) can be appended to the
address using ``@`` separator.
A UNIX socket path where the server listens for remote control commands.
*Default:* :ref:`rundir<server_rundir>`/knot.sock
.. _control_acl:
acl
---
An ordered list of :ref:`references<acl_id>` to ACL rules allowing the remote
control.
*Caution:* This option has no effect with UNIX socket.
*Default:* not set
.. _Remote section:
Remote section
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment