Fixed some errors in configuration and improved 'Running as slave server'.

refs #1877

doc/configuration.texi

@@ -76,8 +76,8 @@ possible combinations in the @code{@ref{log}}.
 @item
 The @code{zones} statement is probably the most important one,
 because it defines the zones that Knot DNS will serve.  In its most simple
-form you define zone by it's name and defined the filename where Knot
-DNS can find the zone contents. You can turn on more detailed semantic
+form you can define a zone by its name and zone file.
+You can turn on more detailed semantic
 checks of zone file in this statement. Refer to @code{@ref{zones List of zone semantic checks}} to see
 which checks are enabled by default and which are optional. If Knot is
 being run as a master server, experimental feature @code{ixfr-from-differences}
@@ -92,9 +92,11 @@ See @ref{Controlling running daemon} for more information. For more information
 Knot DNS doesn't strictly differ between master and slave zones.
 The only requirement is to have @code{xfr-in} @code{zones} statement set for given zone,
 thus allowing both incoming XFR from that remote and using it as the
-zone master. Also, you can specify relative paths for zone file and in that case,
-zone files will be bootstrapped over AXFR and placed in the storage directory,
-specified in @code{storage}. See @code{@ref{zones}} and @code{@ref{storage}}.
+zone master. Note that you need to explicitly allow incoming NOTIFY, otherwise
+the daemon would reject them.
+Also, you can specify paths, relative to the storage directory.
+See @code{@ref{zones}} and @code{@ref{storage}}.
+If the zone file doesn't exist and @code{xfr-in} is set, it will be bootstrapped over AXFR.
 
 @example
 remotes @{
@@ -103,7 +105,7 @@ remotes @{
 zones @{
   example.com @{  
     file "example.com"; # relative to 'storage'
-    xfr-in master;      # uses 'master' remote
+    xfr-in master;      # define 'master' for this zone
     notify-in master;   # also allow NOTIFY from 'master'
   @}
 @}
@@ -126,7 +128,7 @@ remotes @{
 zones @{
   example.com @{  
     file "example.com"; # relative to 'storage'
-    xfr-in master;      # uses 'master' remote
+    xfr-in master;      # define 'master' for this zone
     notify-in master;   # also allow NOTIFY from 'master'
   @}
 @}
@@ -138,7 +140,6 @@ As of now it is not possible to associate multiple keys with a remote.
 @node Master configuration
 @section Master configuration
 
-By default, zones are treated as master as long as they do not have the @code{xfr-in} set.
 You can specify which remotes to allow for outgoing XFR and NOTIFY @code{zones}.
 
 @example
@@ -151,7 +152,7 @@ remotes @{
 zones @{
   example.com @{  
     file "/var/zones/example.com";
-    xfr-out subnet1, subnet2; # uses 'master' remote
+    xfr-out subnet1, subnet2; # allow outgoing transfers
     notify-out slave;
   @}
 @}

doc/installation.texi

@@ -97,17 +97,24 @@ a quite straightforward process using autotools.
 @node Configuring and generating Makefiles
 @subsection Configuring and generating Makefiles
 
-For all available options run:
+If you want to compile from Git sources, you need to bootstrap the
+@command{./configure} file first.
 
 @example
-@command{./configure --help}
+$ autoreconf -i -f
+@end example
+
+For all available configure options run:
+
+@example
+$ ./configure --help
 @end example
 
 If you have trouble with unknown syscalls under valgrind, disable recvmmsg by
 adding a parameter @command{--enable-recvmmsg=no} to configure.
 
 Knot DNS has also support for link time optimizations.
-You can enable it by the configure parameter @command{./configure --enable-lto=no}.
+You can enable it by the configure parameter @command{./configure --enable-lto=yes}.
 It is however disabled by default as it is known to be broken in some compiler
 versions and may result in an unexpected behaviour.
 
@@ -127,7 +134,7 @@ $ ./configure --enable-debug=server,packet --enable-debuglevel=verbose
 In most simple case you can just run configure without any options.
 
 @example
-@command{./configure}
+$ ./configure
 @end example
 
 @node Compilation
@@ -138,7 +145,7 @@ Knot DNS by running @command{make} command, which will produce binaries
 and other related files.
 
 @example
-make
+$ make
 @end example
 
 Knot DNS build process is safe to parallelize
@@ -149,7 +156,7 @@ the compilation.
 For example to use maximum 8 concurrent processes you would use:
 
 @example
-make -j 8
+$ make -j 8
 @end example
 
 @node Installation
@@ -164,7 +171,7 @@ switching to root user, e.g. @command{sudo make install}
 or @command{su -c 'make install'}.
 
 @example
-make install
+$ make install
 @end example
 
 @node Installation from packages
@@ -203,12 +210,12 @@ the root user.
 
 @example
 
-cat >/etc/apt/sources.list.d/knot.list <<EOF
+$ cat >/etc/apt/sources.list.d/knot.list <<EOF
 deb     http://deb.knot-dns.cz/debian/ <codename> main
 deb-src http://deb.knot-dns.cz/debian/ <codename> main
 EOF
-apt-get update
-apt-get install knot
+$ apt-get update
+$ apt-get install knot
 	
 @end example
 
@@ -241,9 +248,9 @@ the PPA.
 
 @example
 
-sudo add-apt-repository ppa:cz.nic-labs/knot-dns
-sudo apt-get update
-sudo apt-get install knot
+$ sudo add-apt-repository ppa:cz.nic-labs/knot-dns
+$ sudo apt-get update
+$ sudo apt-get install knot
 	  
 @end example
 
@@ -256,7 +263,7 @@ in the future, when new version are released.
 @node Installing Knot DNS RPMs on Fedora
 @subsection Installing Knot DNS RPMs on Fedora
 
-There are RPM packages for @code{knot} available for i386 and amd64 targets.
+There are RPM packages for @code{Knot DNS} available for i386 and amd64 targets.
 If you want use the Fedora repository, add a file with the
 following lines into @file{/etc/yum.repos.d/}
 

doc/running.texi

@@ -80,7 +80,7 @@ Slave zones with relative path specified will be placed in the @code{storage} as
 @emph{Compiled zones} - preprocessed zones, for example zone @code{example.com} will be
 placed in @file{STORAGE/example.com.db}.
 @item
-@emph{Journal files} - each zone has a journal file to store changesets for IXFR and
+@emph{Journal files} - each zone has a journal file to store differences for IXFR and
 dynamic updates. Journal for zone @code{example.com} will be
 placed in @file{STORAGE/example.com.diff.db}.
 @item
@@ -97,8 +97,15 @@ placed in @file{STORAGE/example.com.db.crc}.
 
 Running the server as a slave is very straightforward as you usually bootstrap
 zones over AXFR and thus avoid any manual zone compilation.
-There are two ways to start the server - directly or with the @code{knotc} controller tool.
+When a zone is transferred over AXFR, both the compiled zone and the zone file is
+updated, so no further compilation is needed.
+However when IXFR transfer finishes, it stores the differences in a journal file
+and doesn't update the zone file nor compiled zone immediately,
+but there is a timer that checks periodically for new differences and
+updates both zone file and the compiled zone. You can configure this timer
+with the @code{zonefile-sync} statement in @ref{zones}.
 
+There are two ways to start the server - directly or with the @code{knotc} controller tool.
 First, let us start it directly. If you do not pass any configuration, it will try to
 search configuration in default path that is @code{SYSCONFDIR/knot.conf}. The @code{SYSCONFDIR}
 depends on what you passed to the @code{./configure}, usually @code{/etc}.