mirror of
https://gitlab.isc.org/isc-projects/kea
synced 2025-09-01 06:25:34 +00:00
[#2827] reverted src/share/api and updated script
This commit is contained in:
Razvan Becheriu
@@ -95,9 +95,10 @@ following structure:
|
||||
}
|
||||
}
|
||||
|
||||
The ``command`` is the name of the command to execute and is mandatory.
|
||||
The ``arguments`` is a map of the parameters required to carry out the given
|
||||
command. The exact content and format of the map are command-specific.
|
||||
The ``command`` parameter contains the name of the command to execute and it
|
||||
is mandatory.
|
||||
The ``arguments`` map contains the parameters required to carry out the
|
||||
given command. The exact content and format of the map are command specific.
|
||||
|
||||
``service`` is a list of the servers at which the control command is
|
||||
targeted. In the example above, the control command is targeted at the
|
||||
|
||||
@@ -250,11 +250,10 @@ client begins the renewal and rebind processes.
|
||||
See section :ref:`dhcp4-t1-t2-times`
|
||||
for more details on generating T1 and T2.
|
||||
|
||||
The ``interfaces-config`` map specifies the
|
||||
network interfaces on which the server should listen to
|
||||
DHCP messages. The ``interfaces`` parameter specifies a list of
|
||||
network interfaces on which the server should listen. Lists are opened
|
||||
and closed with square brackets, with elements separated by commas. To
|
||||
The ``interfaces-config`` map specifies the network interfaces on which the
|
||||
server should listen to DHCP messages. The ``interfaces`` parameter specifies
|
||||
a list of network interfaces on which the server should listen. Lists are
|
||||
opened and closed with square brackets, with elements separated by commas. To
|
||||
listen on two interfaces, the ``interfaces-config`` element should look like
|
||||
this:
|
||||
|
||||
@@ -2224,9 +2223,9 @@ configuration statement only defines the format of an option and does
|
||||
not set its value(s).
|
||||
|
||||
The ``name``, ``code``, and ``type`` parameters are required; all others
|
||||
are optional. The ``array`` default value is ``false``. The
|
||||
``record-types`` and ``encapsulate`` default values are blank (``""``).
|
||||
The default ``space`` is ``dhcp4``.
|
||||
are optional. The ``array`` parameter default value is ``false``. The
|
||||
``record-types`` and ``encapsulate`` parameters default values are blank
|
||||
(``""``). The default ``space`` is ``dhcp4``.
|
||||
|
||||
Once the new option format is defined, its value is set in the same way
|
||||
as for a standard option. For example, the following commands set a
|
||||
@@ -2275,8 +2274,8 @@ defined in the following way:
|
||||
...
|
||||
}
|
||||
|
||||
The ``type`` is set to ``"record"`` to indicate that the option contains
|
||||
multiple values of different types. These types are given as a
|
||||
The ``type`` parameter is set to ``"record"`` to indicate that the option
|
||||
contains multiple values of different types. These types are given as a
|
||||
comma-separated list in the ``record-types`` field and should be ones
|
||||
from those listed in :ref:`dhcp-types`.
|
||||
|
||||
@@ -2297,10 +2296,10 @@ The option's values are set in an ``option-data`` statement as follows:
|
||||
...
|
||||
}
|
||||
|
||||
The ``csv-format`` is set to ``true`` to indicate that the ``data`` field
|
||||
comprises a comma-separated list of values. The values in ``data``
|
||||
must correspond to the types set in the ``record-types`` field of the
|
||||
option definition.
|
||||
The ``csv-format`` parameter is set to ``true`` to indicate that the ``data``
|
||||
field comprises a comma-separated list of values. The values in ``data`` must
|
||||
correspond to the types set in the ``record-types`` field of the option
|
||||
definition.
|
||||
|
||||
When ``array`` is set to ``true`` and ``type`` is set to ``"record"``, the
|
||||
last field is an array, i.e. it can contain more than one value, as in:
|
||||
@@ -3519,7 +3518,7 @@ conflict with existing entries owned by other DHCPv4 clients.
|
||||
to generate DNS removal requests to D2.
|
||||
|
||||
The DNS entries Kea creates contain a value for TTL (time to live).
|
||||
The ``kea-dhcp4`` calculates that value based on
|
||||
The ``kea-dhcp4`` server calculates that value based on
|
||||
`RFC 4702, Section 5 <https://tools.ietf.org/html/rfc4702#section-5>`__,
|
||||
which suggests that the TTL value be 1/3 of the lease's lifetime, with
|
||||
a minimum value of 10 minutes.
|
||||
@@ -3597,9 +3596,9 @@ following configuration is required:
|
||||
When Does the ``kea-dhcp4`` Server Generate a DDNS Request?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The ``kea-dhcp4`` follows the behavior prescribed for DHCP servers in `RFC
|
||||
4702 <https://tools.ietf.org/html/rfc4702>`__. It is important to keep in
|
||||
mind that ``kea-dhcp4`` makes the initial decision of when and what to
|
||||
The ``kea-dhcp4`` server follows the behavior prescribed for DHCP servers in
|
||||
`RFC 4702 <https://tools.ietf.org/html/rfc4702>`__. It is important to keep
|
||||
in mind that ``kea-dhcp4`` makes the initial decision of when and what to
|
||||
update and forwards that information to D2 in the form of NCRs. Carrying
|
||||
out the actual DNS updates and dealing with such things as conflict
|
||||
resolution are within the purview of D2 itself
|
||||
@@ -3697,8 +3696,8 @@ To override client delegation, issue the following commands:
|
||||
...
|
||||
}
|
||||
|
||||
The ``kea-dhcp4`` always generates DDNS update requests if the client
|
||||
request only contains the Host Name option. In addition, it includes
|
||||
The ``kea-dhcp4`` server always generates DDNS update requests if the
|
||||
client request only contains the Host Name option. In addition, it includes
|
||||
an FQDN option in the response to the client with the FQDN N-S-O flags
|
||||
set to 0-1-0, respectively. The domain name portion of the FQDN option
|
||||
is the name submitted to D2 in the DDNS update request.
|
||||
@@ -4047,9 +4046,9 @@ for a particular subnet. Consider the following simplified server configuration:
|
||||
}
|
||||
}
|
||||
|
||||
The ``match-client-id`` is a boolean value which controls this behavior.
|
||||
The default value of ``true`` indicates that the server will use the
|
||||
client identifier for lease lookups and ``chaddr`` if the first lookup
|
||||
The ``match-client-id`` parameter is a boolean value which controls this
|
||||
behavior. The default value of ``true`` indicates that the server will use
|
||||
the client identifier for lease lookups and ``chaddr`` if the first lookup
|
||||
returns no results. ``false`` means that the server will only use
|
||||
the ``chaddr`` to search for the client's lease. Whether the DHCID for DNS
|
||||
updates is generated from the client identifier or ``chaddr`` is
|
||||
@@ -5041,9 +5040,9 @@ For example:
|
||||
]
|
||||
}
|
||||
|
||||
The ``only-if-required`` parameter is needed here to force
|
||||
evaluation of the class after the lease has been allocated and thus the
|
||||
reserved class has been also assigned.
|
||||
The ``only-if-required`` parameter is needed here to force evaluation
|
||||
of the class after the lease has been allocated and thus the reserved
|
||||
class has been also assigned.
|
||||
|
||||
.. note::
|
||||
|
||||
@@ -5794,8 +5793,8 @@ The ``reservations-lookup-first`` is a boolean parameter which controls whether
|
||||
host reservations lookup should be performed before lease lookup. This parameter
|
||||
has effect only when multi-threading is disabled. When multi-threading is
|
||||
enabled, host reservations lookup is always performed first to avoid lease
|
||||
lookup resource locking. The ``reservations-lookup-first`` defaults to ``false``
|
||||
when multi-threading is disabled.
|
||||
lookup resource locking. The ``reservations-lookup-first`` parameter defaults to
|
||||
``false`` when multi-threading is disabled.
|
||||
|
||||
.. _host_reservations_as_basic_access_control4:
|
||||
|
||||
@@ -5951,6 +5950,7 @@ introduced:
|
||||
|
||||
::
|
||||
|
||||
{
|
||||
"Dhcp4": {
|
||||
"shared-networks": [ {
|
||||
# Name of the shared network. It may be an arbitrary string
|
||||
@@ -5990,6 +5990,7 @@ introduced:
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
As demonstrated in the example, it is possible to mix shared and regular
|
||||
("plain") subnets. Each shared network must have a unique name. This is
|
||||
|
||||
@@ -211,11 +211,10 @@ address to create new connections. ``renew-timer`` and
|
||||
``rebind-timer`` are values (also in seconds) that define T1 and T2 timers, which govern
|
||||
when the client begins the renewal and rebind procedures.
|
||||
|
||||
The ``interfaces-config`` map specifies the
|
||||
network interfaces on which the server should listen to
|
||||
DHCP messages. The ``interfaces`` parameter specifies a list of
|
||||
network interfaces on which the server should listen. Lists are opened
|
||||
and closed with square brackets, with elements separated by commas. To
|
||||
The ``interfaces-config`` map specifies the network interfaces on which the
|
||||
server should listen to DHCP messages. The ``interfaces`` parameter specifies
|
||||
a list of network interfaces on which the server should listen. Lists are
|
||||
opened and closed with square brackets, with elements separated by commas. To
|
||||
listen on two interfaces, the ``interfaces-config`` element should look like
|
||||
this:
|
||||
|
||||
@@ -2059,10 +2058,10 @@ option space, the parameter should be left blank. Note that the ``option-def``
|
||||
configuration statement only defines the format of an option and does
|
||||
not set its value(s).
|
||||
|
||||
The ``name``, ``code``, and ``type`` parameters are required; all
|
||||
others are optional. The ``array`` default value is ``false``. The
|
||||
``record-types`` and ``encapsulate`` default values are blank (``""``).
|
||||
The default ``space`` is ``dhcp6``.
|
||||
The ``name``, ``code``, and ``type`` parameters are required; all others
|
||||
are optional. The ``array`` parameter default value is ``false``. The
|
||||
``record-types`` and ``encapsulate`` parameters default values are blank
|
||||
(``""``). The default ``space`` is ``dhcp6``.
|
||||
|
||||
Once the new option format is defined, its value is set in the same way
|
||||
as for a standard option. For example, the following commands set a
|
||||
@@ -2111,8 +2110,8 @@ defined in the following way:
|
||||
...
|
||||
}
|
||||
|
||||
The ``type`` is set to ``"record"`` to indicate that the option contains
|
||||
multiple values of different types. These types are given as a
|
||||
The ``type`` parameter is set to ``"record"`` to indicate that the option
|
||||
contains multiple values of different types. These types are given as a
|
||||
comma-separated list in the ``record-types`` field and should be ones
|
||||
from those listed in :ref:`dhcp-types`.
|
||||
|
||||
@@ -2134,10 +2133,10 @@ follows:
|
||||
...
|
||||
}
|
||||
|
||||
The ``csv-format`` is set to ``true`` to indicate that the ``data`` field
|
||||
comprises a comma-separated list of values. The values in ``data``
|
||||
must correspond to the types set in the ``record-types`` field of the
|
||||
option definition.
|
||||
The ``csv-format`` parameter is set to ``true`` to indicate that the ``data``
|
||||
field comprises a comma-separated list of values. The values in ``data`` must
|
||||
correspond to the types set in the ``record-types`` field of the option
|
||||
definition.
|
||||
|
||||
When ``array`` is set to ``true`` and ``type`` is set to ``"record"``, the
|
||||
last field is an array, i.e. it can contain more than one value, as in:
|
||||
@@ -3173,9 +3172,9 @@ configuration is required:
|
||||
When Does the ``kea-dhcp6`` Server Generate a DDNS Request?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The ``kea-dhcp6`` follows the behavior prescribed for DHCP servers in `RFC
|
||||
4704 <https://tools.ietf.org/html/rfc4704>`__. It is important to keep in
|
||||
mind that ``kea-dhcp6`` makes the initial decision of when and what to
|
||||
The ``kea-dhcp6`` server follows the behavior prescribed for DHCP servers in
|
||||
`RFC 4704 <https://tools.ietf.org/html/rfc4704>`__. It is important to keep
|
||||
in mind that ``kea-dhcp6`` makes the initial decision of when and what to
|
||||
update and forwards that information to D2 in the form of NCRs. Carrying
|
||||
out the actual DNS updates and dealing with such things as conflict
|
||||
resolution are within the purview of D2 itself
|
||||
@@ -3276,8 +3275,8 @@ To override client delegation, issue the following commands:
|
||||
...
|
||||
}
|
||||
|
||||
The ``kea-dhcp6`` always generates DDNS update requests if the client
|
||||
request only contains the Host Name option. In addition, it includes
|
||||
The ``kea-dhcp6`` server always generates DDNS update requests if the
|
||||
client request only contains the Host Name option. In addition, it includes
|
||||
an FQDN option in the response to the client with the FQDN N-S-O flags
|
||||
set to 0-1-0, respectively. The domain name portion of the FQDN option
|
||||
is the name submitted to D2 in the DDNS update request.
|
||||
@@ -5183,6 +5182,7 @@ introduced:
|
||||
|
||||
::
|
||||
|
||||
{
|
||||
"Dhcp6": {
|
||||
"shared-networks": [ {
|
||||
# Name of the shared network. It may be an arbitrary string
|
||||
@@ -5227,6 +5227,7 @@ introduced:
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
As demonstrated in the example, it is possible to mix shared and regular
|
||||
("plain") subnets. Each shared network must have a unique name. This is
|
||||
|
||||
@@ -9,7 +9,7 @@ be used in conjunction with the available CB hook libraries implementing
|
||||
the common APIs to create, read, update, and delete (CRUD) the
|
||||
configuration information in the respective databases. For example:
|
||||
the ``mysql_cb`` hook library implements this API for MySQL while the
|
||||
``pgsql_cg`` hook library implements this API for PostgreSQL.
|
||||
``pgsql_cb`` hook library implements this API for PostgreSQL.
|
||||
To manage the configuration information in a MySQL database, both the
|
||||
``mysql_cb`` and ``cb_cmds`` libraries must be loaded by the server used for the
|
||||
configuration management.
|
||||
@@ -1097,8 +1097,8 @@ For example:
|
||||
}
|
||||
}
|
||||
|
||||
The "dhcp4" is the top-level option space where the standard DHCPv4 options
|
||||
belong. The ``server-tags`` parameter is mandatory and must include a
|
||||
The "dhcp4" value represents the top-level option space where the standard DHCPv4
|
||||
options belong. The ``server-tags`` parameter is mandatory and must include a
|
||||
single option tag or the keyword "all". If the explicit server tag is specified,
|
||||
this command attempts to delete a global option associated with this
|
||||
server. If there is no such option associated with the given server, no option
|
||||
@@ -1296,8 +1296,8 @@ network "fancy".
|
||||
}
|
||||
}
|
||||
|
||||
The "dhcp4" is the top-level option space where the standard DHCPv4 options
|
||||
belong. The ``server-tags`` parameter cannot be specified for this command.
|
||||
The "dhcp4" value represents the top-level option space where the standard DHCPv4
|
||||
options belong. The ``server-tags`` parameter cannot be specified for this command.
|
||||
|
||||
.. _command-remote-option4-network-set:
|
||||
|
||||
@@ -1382,8 +1382,8 @@ option. To delete a subnet level option, the
|
||||
}
|
||||
}
|
||||
|
||||
The "dhcp6" is the top-level option space where the standard DHCPv6 options
|
||||
belong. The ``server-tags`` parameter cannot be specified for this command.
|
||||
The "dhcp6" value represents the top-level option space where the standard DHCPv6
|
||||
options belong. The ``server-tags`` parameter cannot be specified for this command.
|
||||
|
||||
.. _command-remote-option6-pd-pool-set:
|
||||
|
||||
@@ -1475,8 +1475,8 @@ pool:
|
||||
}
|
||||
}
|
||||
|
||||
The "dhcp4" is the top-level option space where the standard DHCPv4 options
|
||||
belong. The ``server-tags`` parameter cannot be specified for this command.
|
||||
The "dhcp4" value represents the top-level option space where the standard DHCPv4
|
||||
options belong. The ``server-tags`` parameter cannot be specified for this command.
|
||||
|
||||
.. _command-remote-option4-pool-set:
|
||||
|
||||
@@ -1564,8 +1564,8 @@ having an identifier of 123.
|
||||
}
|
||||
}
|
||||
|
||||
The "dhcp4" is the top-level option space where the standard DHCPv4 options
|
||||
belong. The ``server-tags`` parameter cannot be specified for this command.
|
||||
The "dhcp4" value represents the top-level option space where the standard DHCPv4
|
||||
options belong. The ``server-tags`` parameter cannot be specified for this command.
|
||||
|
||||
.. _command-remote-option4-subnet-set:
|
||||
|
||||
|
||||
@@ -269,7 +269,7 @@ follows:
|
||||
}
|
||||
}
|
||||
|
||||
The ``reservation-get`` typically returns the result 0 when a query was
|
||||
``reservation-get`` typically returns the result 0 when a query was
|
||||
conducted properly. In particular, 0 is returned when the host was not
|
||||
found. If the query was successful, the host parameters are
|
||||
returned. An example of a query that did not find the host looks as
|
||||
@@ -685,7 +685,7 @@ follows:
|
||||
}
|
||||
}
|
||||
|
||||
The ``reservation-del`` returns a result of 0 when the host deletion was
|
||||
``reservation-del`` returns a result of 0 when the host deletion was
|
||||
successful, or 1 if it failed. Descriptive text is provided in the event of
|
||||
an error. Here are some examples of possible results:
|
||||
|
||||
|
||||
@@ -166,8 +166,8 @@ subnet. For example:
|
||||
}
|
||||
}
|
||||
|
||||
The ``lease6-add`` can also be used to add leases for IPv6 prefixes. In this
|
||||
case there are three additional parameters that must be specified:
|
||||
The ``lease6-add`` command can also be used to add leases for IPv6 prefixes.
|
||||
In this case there are three additional parameters that must be specified:
|
||||
``subnet-id``, ``type`` (set to "IA_PD"), and prefix length. The actual
|
||||
prefix is set using the ``ip-address`` field. Note that Kea cannot guess
|
||||
``subnet-id`` values for prefixes; they must be specified explicitly. For
|
||||
@@ -840,7 +840,7 @@ This parameter defaults to ``false``. An example of its use is shown below:
|
||||
}
|
||||
|
||||
|
||||
The ``lease4-del`` and ``lease6-del`` return a result that indicates the outcome
|
||||
``lease4-del`` and ``lease6-del`` return a result that indicates the outcome
|
||||
of the operation. It has one of the following values: 0 (success), 1 (error),
|
||||
or 3 (empty). The empty result means that a query has been completed properly,
|
||||
but the object (a lease, in this case) has not been found.
|
||||
@@ -1000,11 +1000,10 @@ An example of the ``lease6-resend-ddns`` query is:
|
||||
}
|
||||
}
|
||||
|
||||
The ``lease4-resend-ddns`` and ``lease6-resend-ddns`` return an indication of the
|
||||
result of the operation.
|
||||
it has one of the following values: 0 (success), 1 (error), or 3 (empty). An empty
|
||||
result means that a query has been completed properly, but the object (a lease in
|
||||
this case) has not been found.
|
||||
``lease4-resend-ddns`` and ``lease6-resend-ddns`` return an indication of the
|
||||
result of the operation. It has one of the following values: 0 (success), 1 (error),
|
||||
or 3 (empty). An empty result means that a query has been completed properly, but the
|
||||
object (a lease in this case) has not been found.
|
||||
|
||||
A successful result does not mean that DNS has been successfully updated; it
|
||||
indicates that a request to update DNS has been successfully created and
|
||||
|
||||
Reference in New Issue
Block a user