Age | Commit message (Collapse) | Author |
|
(cherry picked from commit 59e5b5eb4c0507f9d3831483152a748b58560bfd)
|
|
(cherry picked from commit 90dffcb3c14ec976fecae32d19a979f05a40d9c8)
|
|
IPv4 DHCP uses "dns-server" to specify one or more name-servers for a given
pool. In order to use the same CLI syntax this should be renamed to name-server,
which is already the case for DHCPv6.
(cherry picked from commit e2f9f4f4e8b2e961a58d935d09798ddb4e1e0460)
|
|
(cherry picked from commit 794f193d11c8c1b5fed78f4e40280480446ab593)
|
|
(cherry picked from commit 2318c874c4ec43076c2664e473f7273928d9f2a6)
|
|
(cherry picked from commit 117533482d29ce0bd1bc7f3a3f2536921c16565c)
|
|
|
|
Error while copying statement from preference node.
|
|
Migrate the domain-search node (which occurs three times) to an includable
snippet. Also re-use the fqdn validator to keep the regex patterns to as few
locations as possible.
|
|
This commit adds support for configuring the DHCPv6 server to serve
"stateless" DHCPv6 clients (those that send an information-request
message and do not request an address).
The change introduces a `common-options` node at the
`shared-network-name` level, which allows specifying options
applicable to clients regardless of subnet assigned (or in the case of
stateless clients, when no subnet is assigned). Parameters specified
at the subnet level take precedence over those set at the
shared-network level.
Presently, only parameters that are meaningful to stateless clients
have been exposed under `common-options`, as there is no precedent of
exposing parameters at multiple levels under the current DHCPv4 or
DHCPv6 configuration syntax. If desired, additional parameters could
certainly be added with relative ease.
|
|
|
|
The subnet specific nodes sip-server-address & sip-server-name do the same for
the user - specify a SIP server. Only the backend is rendered in a different
way, as ISC DHCPv6 expects different options. There is absolutely no need for
the user to distinguish between both two nodes.
|
|
A lot of XML code is duplicated (VLAN, interface address) for instance. Such
XML definitions should be moved to feature.xml.i files and then just pulled in
via GCC preprocessor #include definition in e.g. bond or ethernet definitions.
This will give us the ability to single-source repeating node definitions as:
* Interface Address
* Interface Description
* Interface Disable
* VLAN (both vif-s and vif-c)
The .in suffix of the interface-definitions is a marker that those files are
input files to the GCC preprocessor. They will be rendered into proper XML
files in the build directory.
Some node definitions have been reworder to remove escaped double quote
occurances which would have been warned about by the GCC preprocessor.
|