Commit eb06cb8d authored by Xie Jiagui's avatar Xie Jiagui
Browse files

Merge branch 'master' into trac1310

parents e35e9b8a 5de824f5
bind10-devel-20111128 released on November 28, 2011
331. [bug] shane
Fixed a bug in data source library where a zone with more labels
than an out-of-bailiwick name server would cause an exception to
be raised.
(Trac #1430, git 81f62344db074bc5eea3aaf3682122fdec6451ad)
330. [bug] jelte
Fixed a bug in b10-auth where it would sometimes fail because it
tried to check for queued msgq messages before the session was
fully running.
(git c35d0dde3e835fc5f0a78fcfcc8b76c74bc727ca)
329. [doc] vorner, jreed
Document the bind10 run control configuration in guide and
manual page.
(Trac #1341, git c1171699a2b501321ab54207ad26e5da2b092d63)
328. [func] jelte
b10-auth now passes IXFR requests on to b10-xfrout, and no longer
responds to them with NOTIMPL.
(Trac #1390, git ab3f90da16d31fc6833d869686e07729d9b8c135)
327. [func] jinmei
b10-xfrout now supports IXFR. (Right now there is no user
configurable parameter about this feature; b10-xfrout will
always respond to IXFR requests according to RFC1995).
(Trac #1371 and #1372, git 80c131f5b0763753d199b0fb9b51f10990bcd92b)
326. [build]* jinmei
Added a check script for the SQLite3 schema version. It will be
run at the beginning of 'make install', and if it detects an old
version of schema, installation will stop. You'll then need to
upgrade the database file by following the error message.
(Trac #1404, git a435f3ac50667bcb76dca44b7b5d152f45432b57)
325. [func] jinmei
Python isc.datasrc: added interfaces for difference management:
DataSourceClient.get_updater() now has the 'journaling' parameter
to enable storing diffs to the data source, and a new class
ZoneJournalReader was introduced to retrieve them, which can be
created by the new DataSourceClient.get_journal_reader() method.
(Trac #1333, git 3e19362bc1ba7dc67a87768e2b172c48b32417f5,
git 39def1d39c9543fc485eceaa5d390062edb97676)
324. [bug] jinmei
Fixed reference leak in the isc.log Python module. Most of all
BIND 10 Python programs had memory leak (even though the pace of
leak may be slow) due to this bug.
(Trac #1359, git 164d651a0e4c1059c71f56b52ea87ac72b7f6c77)
323. [bug] jinmei
b10-xfrout incorrectly skipped adding TSIG RRs to some
intermediate responses (when TSIG is to be used for the
responses). While RFC2845 optionally allows to skip intermediate
TSIGs (as long as the digest for the skipped part was included
in a later TSIG), the underlying TSIG API doesn't support this
mode of signing.
(Trac #1370, git 76fb414ea5257b639ba58ee336fae9a68998b30d)
322. [func] jinmei
datasrc: Added C++ API for retrieving difference of two versions
of a zone. A new ZoneJournalReader class was introduced for this
purpose, and a corresponding factory method was added to
DataSourceClient.
(Trac #1332, git c1138d13b2692fa3a4f2ae1454052c866d24e654)
321. [func]* jinmei
b10-xfrin now installs IXFR differences into the underlying data
source (if it supports journaling) so that the stored differences
can be used for subsequent IXFR-out transactions.
Note: this is a backward incompatibility change for older sqlite3
database files. They need to be upgraded to have a "diffs" table.
(Trac #1376, git 1219d81b49e51adece77dc57b5902fa1c6be1407)
320. [func]* vorner
The --brittle switch was removed from the bind10 executable.
It didn't work after change #316 (Trac #213) and the same
effect can be accomplished by declaring all components as core.
(Trac #1340, git f9224368908dd7ba16875b0d36329cf1161193f0)
319. [func] naokikambe
b10-stats-httpd was updated. In addition of the access to all
statistics items of all modules, the specified item or the items
of the specified module name can be accessed. For example, the
URI requested by using the feature is showed as
"/bind10/statistics/xml/Auth" or
"/bind10/statistics/xml/Auth/queries.tcp". The list of all possible
module names and all possible item names can be showed in the
root document, whose URI is "/bind10/statistics/xml". This change
is not only for the XML documents but also is for the XSD and
XSL documents.
(Trac #917, git b34bf286c064d44746ec0b79e38a6177d01e6956)
318. [func] stephen
Add C++ API for accessing zone difference information in
database-based data sources.
(Trac #1330, git 78770f52c7f1e7268d99e8bfa8c61e889813bb33)
317. [func] vorner
datasrc: the getUpdater method of DataSourceClient supports an
optional 'journaling' parameter to indicate the generated updater
to store diffs. The database based derived class implements this
extension.
(Trac #1331, git 713160c9bed3d991a00b2ea5e7e3e7714d79625d)
316. [func]* vorner
The configuration of what parts of the system run is more flexible now.
Everything that should run must have an entry in Boss/components.
The configuration of what parts of the system run is more
flexible now. Everything that should run must have an
entry in Boss/components.
(Trac #213, git 08e1873a3593b4fa06754654d22d99771aa388a6)
315. [func] tomek
......@@ -70,7 +178,7 @@
automatically.
(Trac #1279, git cd3588c9020d0310f949bfd053c4d3a4bd84ef88)
306. [bug] Stephen
306. [bug] stephen
Boss process now waits for the configuration manager to initialize
itself before continuing with startup. This fixes a race condition
whereby the Boss could start the configuration manager and then
......@@ -484,7 +592,7 @@ bind10-devel-20110705 released on July 05, 2011
(Trac #542, git 1aa773d84cd6431aa1483eb34a7f4204949a610f)
243. [func]* feng
Add optional hmac algorithm SHA224/384/812.
Add optional hmac algorithm SHA224/384/512.
(Trac #782, git 77d792c9d7c1a3f95d3e6a8b721ac79002cd7db1)
bind10-devel-20110519 released on May 19, 2011
......
SUBDIRS = doc src tests
SUBDIRS = compatcheck doc src tests
USE_LCOV=@USE_LCOV@
LCOV=@LCOV@
GENHTML=@GENHTML@
......
noinst_SCRIPTS = sqlite3-difftbl-check.py
# We're going to abuse install-data-local for a pre-install check.
# This is to be considered a short term hack and is expected to be removed
# in a near future version.
install-data-local:
$(PYTHON) sqlite3-difftbl-check.py \
$(localstatedir)/$(PACKAGE)/zone.sqlite3
This directory is a collection of compatibility checker programs.
They will be run before any other installation attempts on 'make install'
to see if the installation causes any substantial compatibility problems
with existing configuratons. If any checker program finds an issue,
'make install' will stop at that point.
#!@PYTHON@
# Copyright (C) 2011 Internet Systems Consortium.
#
# Permission to use, copy, modify, and distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SYSTEMS CONSORTIUM
# DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
# INTERNET SYSTEMS CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT,
# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING
# FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
# NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
# WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
import os, sqlite3, sys
from optparse import OptionParser
usage = 'usage: %prog [options] db_file'
parser = OptionParser(usage=usage)
parser.add_option("-u", "--upgrade", action="store_true",
dest="upgrade", default=False,
help="Upgrade the database file [default: %default]")
(options, args) = parser.parse_args()
if len(args) == 0:
parser.error('missing argument')
db_file = args[0]
# If the file doesn't exist, there's nothing to do
if not os.path.exists(db_file):
sys.exit(0)
conn = sqlite3.connect(db_file)
cur = conn.cursor()
try:
# This can be anything that works iff the "diffs" table exists
cur.execute('SELECT name FROM diffs DESC LIMIT 1')
except sqlite3.OperationalError as ex:
# If it fails with 'no such table', create a new one or fail with
# warning depending on the --upgrade command line option.
if str(ex) == 'no such table: diffs':
if options.upgrade:
cur.execute('CREATE TABLE diffs (id INTEGER PRIMARY KEY, ' +
'zone_id INTEGER NOT NULL, ' +
'version INTEGER NOT NULL, ' +
'operation INTEGER NOT NULL, ' +
'name STRING NOT NULL COLLATE NOCASE, ' +
'rrtype STRING NOT NULL COLLATE NOCASE, ' +
'ttl INTEGER NOT NULL, rdata STRING NOT NULL)')
else:
sys.stdout.write('Found an older version of SQLite3 DB file: ' +
db_file + '\n' + "Perform '" + os.getcwd() +
"/sqlite3-difftbl-check.py --upgrade " +
db_file + "'\n" +
'before continuing install.\n')
sys.exit(1)
conn.close()
......@@ -2,7 +2,7 @@
# Process this file with autoconf to produce a configure script.
AC_PREREQ([2.59])
AC_INIT(bind10-devel, 20111021, bind10-dev@isc.org)
AC_INIT(bind10-devel, 20111129, bind10-dev@isc.org)
AC_CONFIG_SRCDIR(README)
AM_INIT_AUTOMAKE
AC_CONFIG_HEADERS([config.h])
......@@ -816,6 +816,7 @@ AM_CONDITIONAL(INSTALL_CONFIGURATIONS, test x$install_configurations = xyes || t
AC_CONFIG_FILES([Makefile
doc/Makefile
doc/guide/Makefile
compatcheck/Makefile
src/Makefile
src/bin/Makefile
src/bin/bind10/Makefile
......@@ -937,6 +938,7 @@ AC_CONFIG_FILES([Makefile
tests/tools/badpacket/tests/Makefile
])
AC_OUTPUT([doc/version.ent
compatcheck/sqlite3-difftbl-check.py
src/bin/cfgmgr/b10-cfgmgr.py
src/bin/cfgmgr/tests/b10-cfgmgr_test.py
src/bin/cmdctl/cmdctl.py
......@@ -1016,6 +1018,7 @@ AC_OUTPUT([doc/version.ent
tests/system/ixfr/in-3/setup.sh
tests/system/ixfr/in-4/setup.sh
], [
chmod +x compatcheck/sqlite3-difftbl-check.py
chmod +x src/bin/cmdctl/run_b10-cmdctl.sh
chmod +x src/bin/xfrin/run_b10-xfrin.sh
chmod +x src/bin/xfrout/run_b10-xfrout.sh
......
This diff is collapsed.
......@@ -2,7 +2,7 @@
Administrator Reference for BIND 10
This is the reference guide for BIND 10 version 20110809.
This is the reference guide for BIND 10 version 20111021.
Copyright (c) 2010-2011 Internet Systems Consortium, Inc.
......@@ -12,7 +12,7 @@ Administrator Reference for BIND 10
Consortium (ISC). It includes DNS libraries and modular components for
controlling authoritative and recursive DNS servers.
This is the reference guide for BIND 10 version 20110809. The most
This is the reference guide for BIND 10 version 20111021. The most
up-to-date version of this document (in PDF, HTML, and plain text
formats), along with other documents for BIND 10, can be found at
http://bind10.isc.org/docs.
......@@ -55,6 +55,8 @@ Administrator Reference for BIND 10
Starting BIND 10
Configuration of started processes
4. Command channel
5. Configuration manager
......@@ -105,6 +107,10 @@ Administrator Reference for BIND 10
Logging Message Format
List of Tables
3.1.
Chapter 1. Introduction
Table of Contents
......@@ -124,7 +130,7 @@ Chapter 1. Introduction
Note
This guide covers the experimental prototype of BIND 10 version 20110809.
This guide covers the experimental prototype of BIND 10 version 20111021.
Note
......@@ -427,24 +433,28 @@ Chapter 3. Starting BIND10 with bind10
Starting BIND 10
Configuration of started processes
BIND 10 provides the bind10 command which starts up the required
processes. bind10 will also restart processes that exit unexpectedly. This
is the only command needed to start the BIND 10 system.
processes. bind10 will also restart some processes that exit unexpectedly.
This is the only command needed to start the BIND 10 system.
After starting the b10-msgq communications channel, bind10 connects to it,
runs the configuration manager, and reads its own configuration. Then it
starts the other modules.
The b10-msgq and b10-cfgmgr services make up the core. The b10-msgq daemon
provides the communication channel between every part of the system. The
b10-cfgmgr daemon is always needed by every module, if only to send
information about themselves somewhere, but more importantly to ask about
their own settings, and about other modules. The bind10 master process
will also start up b10-cmdctl for admins to communicate with the system,
b10-auth for authoritative DNS service or b10-resolver for recursive name
service, b10-stats for statistics collection, b10-xfrin for inbound DNS
zone transfers, b10-xfrout for outbound DNS zone transfers, and
b10-zonemgr for secondary service.
The b10-sockcreator, b10-msgq and b10-cfgmgr services make up the core.
The b10-msgq daemon provides the communication channel between every part
of the system. The b10-cfgmgr daemon is always needed by every module, if
only to send information about themselves somewhere, but more importantly
to ask about their own settings, and about other modules. The
b10-sockcreator will allocate sockets for the rest of the system.
In its default configuration, the bind10 master process will also start up
b10-cmdctl for admins to communicate with the system, b10-auth for
authoritative DNS service, b10-stats for statistics collection, b10-xfrin
for inbound DNS zone transfers, b10-xfrout for outbound DNS zone
transfers, and b10-zonemgr for secondary service.
Starting BIND 10
......@@ -457,6 +467,110 @@ Starting BIND 10
names for the Python-based daemons will be renamed to better identify them
instead of just "python". This is not needed on some operating systems.
Configuration of started processes
The processes to be started can be configured, with the exception of the
b10-sockcreator, b10-msgq and b10-cfgmgr.
The configuration is in the Boss/components section. Each element
represents one component, which is an abstraction of a process (currently
there's also one component which doesn't represent a process). If you
didn't want to transfer out at all (your server is a slave only), you
would just remove the corresponding component from the set, like this and
the process would be stopped immediately (and not started on the next
startup):
> config remove Boss/components b10-xfrout
> config commit
To add a process to the set, let's say the resolver (which not started by
default), you would do this:
> config add Boss/components b10-resolver
> config set Boss/components/b10-resolver/special resolver
> config set Boss/components/b10-resolver/kind needed
> config set Boss/components/b10-resolver/priority 10
> config commit
Now, what it means. We add an entry called b10-resolver. It is both a name
used to reference this component in the configuration and the name of the
process to start. Then we set some parameters on how to start it.
The special one is for components that need some kind of special care
during startup or shutdown. Unless specified, the component is started in
usual way. This is the list of components that need to be started in a
special way, with the value of special used for them:
Table 3.1.
+------------------------------------------------------------------------+
| Component | Special | Description |
|--------------+----------+----------------------------------------------|
| b10-auth | auth | Authoritative server |
|--------------+----------+----------------------------------------------|
| b10-resolver | resolver | The resolver |
|--------------+----------+----------------------------------------------|
| b10-cmdctl | cmdctl | The command control (remote control |
| | | interface) |
|--------------+----------+----------------------------------------------|
| setuid | setuid | Virtual component, see below |
+------------------------------------------------------------------------+
The kind specifies how a failure of the component should be handled. If it
is set to "dispensable" (the default unless you set something else), it
will get started again if it fails. If it is set to "needed" and it fails
at startup, the whole bind10 shuts down and exits with error exit code.
But if it fails some time later, it is just started again. If you set it
to "core", you indicate that the system is not usable without the
component and if such component fails, the system shuts down no matter
when the failure happened. This is the behaviour of the core components
(the ones you can't turn off), but you can declare any other components as
core as well if you wish (but you can turn these off, they just can't
fail).
The priority defines order in which the components should start. The ones
with higher number are started sooner than the ones with lower ones. If
you don't set it, 0 (zero) is used as the priority.
There are other parameters we didn't use in our example. One of them is
"address". It is the address used by the component on the b10-msgq message
bus. The special components already know their address, but the usual ones
don't. The address is by convention the thing after b10-, with the first
letter capital (eg. b10-stats would have "Stats" as its address).
The last one is process. It is the name of the process to be started. It
defaults to the name of the component if not set, but you can use this to
override it.
Note
This system allows you to start the same component multiple times (by
including it in the configuration with different names, but the same
process setting). However, the rest of the system doesn't expect such
situation, so it would probably not do what you want. Such support is yet
to be implemented.
Note
The configuration is quite powerful, but that includes a lot of space for
mistakes. You could turn off the b10-cmdctl, but then you couldn't change
it back the usual way, as it would require it to be running (you would
have to find and edit the configuration directly). Also, some modules
might have dependencies -- b10-stats-httpd need b10-stats, b10-xfrout
needs the b10-auth to be running, etc.
In short, you should think twice before disabling something here.
Now, to the mysterious setuid virtual component. If you use the -u option
to start the bind10 as root, but change the user later, we need to start
the b10-auth or b10-resolver as root (until the socket creator is
finished). So we need to specify the time when the switch from root do the
given user happens and that's what the setuid component is for. The switch
is done at the time the setuid component would be started, if it was a
process. The default configuration contains the setuid component with
priority 5, b10-auth has 10 to be started before the switch and everything
else is without priority, so it is started after the switch.
Chapter 4. Command channel
The BIND 10 components use the b10-msgq message routing daemon to
......@@ -739,15 +853,55 @@ Trigger an Incoming Zone Transfer Manually
Chapter 10. Outbound Zone Transfers
The b10-xfrout process is started by bind10. When the b10-auth
authoritative DNS server receives an AXFR request, b10-xfrout sends the
zone. This is used to provide master DNS service to share zones to
secondary name servers. The b10-xfrout is also used to send NOTIFY
messages to slaves.
authoritative DNS server receives an AXFR or IXFR request, b10-auth
internally forwards the request to b10-xfrout, which handles the rest of
request processing. This is used to provide primary DNS service to share
zones to secondary name servers. The b10-xfrout is also used to send
NOTIFY messages to secondary servers.
A global or per zone transfer_acl configuration can be used to control
accessibility of the outbound zone transfer service. By default,
b10-xfrout allows any clients to perform zone transfers for any zones:
> config show Xfrout/transfer_acl
Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default)
You can change this to, for example, rejecting all transfer requests by
default while allowing requests for the transfer of zone "example.com"
from 192.0.2.1 and 2001:db8::1 as follows:
> config set Xfrout/transfer_acl[0] {"action": "REJECT"}
> config add Xfrout/zone_config
> config set Xfrout/zone_config[0]/origin "example.com"
> config set Xfrout/zone_config[0]/transfer_acl [{"action": "ACCEPT", "from": "192.0.2.1"},
{"action": "ACCEPT", "from": "2001:db8::1"}]
> config commit
Note
In the above example the lines for transfer_acl were divided for
readability. In the actual input it must be in a single line.
If you want to require TSIG in access control, a separate TSIG "key ring"
must be configured specifically for b10-xfrout as well as a system wide
key ring, both containing a consistent set of keys. For example, to change
the previous example to allowing requests from 192.0.2.1 signed by a TSIG
with a key name of "key.example", you'll need to do this:
> config set tsig_keys/keys ["key.example:<base64-key>"]
> config set Xfrout/tsig_keys/keys ["key.example:<base64-key>"]
> config set Xfrout/zone_config[0]/transfer_acl [{"action": "ACCEPT", "from": "192.0.2.1", "key": "key.example"}]
> config commit
The first line of configuration defines a system wide key ring. This is
necessary because the b10-auth server also checks TSIGs and it uses the
system wide configuration.
Note
The current development release of BIND 10 only supports AXFR. (IXFR is
not supported.) Access control is not yet provided.
In a future version, b10-xfrout will also use the system wide TSIG
configuration. The way to specify zone specific configuration (ACLs, etc)
is likely to be changed, too.
Chapter 11. Secondary Manager
......@@ -777,8 +931,13 @@ Chapter 12. Recursive Name Server
authoritative or resolver or both. By default, it starts the authoritative
service. You may change this using bindctl, for example:
> config set Boss/start_auth false
> config set Boss/start_resolver true
> config remove Boss/components b10-xfrout
> config remove Boss/components b10-xfrin
> config remove Boss/components b10-auth
> config add Boss/components b10-resolver
> config set Boss/components/b10-resolver/special resolver
> config set Boss/components/b10-resolver/kind needed
> config set Boss/components/b10-resolver/priority 10
> config commit
The master bind10 will stop and start the desired services.
......
......@@ -706,7 +706,7 @@ Debian and Ubuntu:
BIND 10 provides the <command>bind10</command> command which
starts up the required processes.
<command>bind10</command>
will also restart processes that exit unexpectedly.
will also restart some processes that exit unexpectedly.
This is the only command needed to start the BIND 10 system.
</para>
......@@ -718,17 +718,22 @@ Debian and Ubuntu:
</para>
<para>
The <command>b10-msgq</command> and <command>b10-cfgmgr</command>
The <command>b10-sockcreator</command>, <command>b10-msgq</command> and
<command>b10-cfgmgr</command>
services make up the core. The <command>b10-msgq</command> daemon
provides the communication channel between every part of the system.
The <command>b10-cfgmgr</command> daemon is always needed by every
module, if only to send information about themselves somewhere,
but more importantly to ask about their own settings, and
about other modules.
The <command>bind10</command> master process will also start up
about other modules. The <command>b10-sockcreator</command> will
allocate sockets for the rest of the system.
</para>
<para>
In its default configuration, the <command>bind10</command>
master process will also start up
<command>b10-cmdctl</command> for admins to communicate with the
system, <command>b10-auth</command> for authoritative DNS service or
<command>b10-resolver</command> for recursive name service,
system, <command>b10-auth</command> for authoritative DNS service,
<command>b10-stats</command> for statistics collection,
<command>b10-xfrin</command> for inbound DNS zone transfers,
<command>b10-xfrout</command> for outbound DNS zone transfers,
......@@ -754,6 +759,159 @@ Debian and Ubuntu:
</note>
</section>
<section id="bind10.config">
<title>Configuration of started processes</title>
<para>
The processes to be started can be configured, with the exception
of the <command>b10-sockcreator</command>, <command>b10-msgq</command>
and <command>b10-cfgmgr</command>.
</para>
<para>
The configuration is in the Boss/components section. Each element
represents one component, which is an abstraction of a process
(currently there's also one component which doesn't represent
a process). If you didn't want to transfer out at all (your server
is a slave only), you would just remove the corresponding component
from the set, like this and the process would be stopped immediately
(and not started on the next startup):
<screen>&gt; <userinput>config remove Boss/components b10-xfrout</userinput>
&gt; <userinput>config commit</userinput></screen>
</para>
<para>
To add a process to the set, let's say the resolver (which not started
by default), you would do this:
<screen>&gt; <userinput>config add Boss/components b10-resolver</userinput>
&gt; <userinput>config set Boss/components/b10-resolver/special resolver</userinput>
&gt; <userinput>config set Boss/components/b10-resolver/kind needed</userinput>
&gt; <userinput>config set Boss/components/b10-resolver/priority 10</userinput>
&gt; <userinput>config commit</userinput></screen></para>
<para>
Now, what it means. We add an entry called b10-resolver. It is both a
name used to reference this component in the configuration and the
name of the process to start. Then we set some parameters on how to
start it.
</para>
<para>
The special one is for components that need some kind of special care
during startup or shutdown. Unless specified, the component is started
in usual way. This is the list of components that need to be started
in a special way, with the value of special used for them:
<table>
<tgroup cols='3' align='left'>
<colspec colname='component'/>
<colspec colname='special'/>
<colspec colname='description'/>
<thead><row><entry>Component</entry><entry>Special</entry><entry>Description</entry></row></thead>
<tbody>
<row><entry>b10-auth</entry><entry>auth</entry><entry>Authoritative server</entry></row>
<row><entry>b10-resolver</entry><entry>resolver</entry><entry>The resolver</entry></row>
<row><entry>b10-cmdctl</entry><entry>cmdctl</entry><entry>The command control (remote control interface)</entry></row>
<row><entry>setuid</entry><entry>setuid</entry><entry>Virtual component, see below</entry></row>
<!-- TODO Either add xfrin and xfrout as well or clean up the workarounds in boss before the release -->
</tbody>
</tgroup>
</table>
</para>
<para>
The kind specifies how a failure of the component should
be handled. If it is set to <quote>dispensable</quote>
(the default unless you set something else), it will get
started again if it fails. If it is set to <quote>needed</quote>
and it fails at startup, the whole <command>bind10</command>
shuts down and exits with error exit code. But if it fails
some time later, it is just started again. If you set it
to <quote>core</quote>, you indicate that the system is
not usable without the component and if such component
fails, the system shuts down no matter when the failure
happened. This is the behaviour of the core components
(the ones you can't turn off), but you can declare any
other components as core as well if you wish (but you can
turn these off, they just can't fail).
</para>
<para>
The priority defines order in which the components should start.
The ones with higher number are started sooner than the ones with
lower ones. If you don't set it, 0 (zero) is used as the priority.
</para>