mirror of
https://gitlab.isc.org/isc-projects/kea
synced 2025-09-03 07:25:18 +00:00
[#118,!113] FAQ section removed.
This commit is contained in:
Tomek Mrugalski
@@ -9,7 +9,7 @@ DOCBOOK = kea-guide.xml intro.xml quickstart.xml install.xml admin.xml config.xm
|
|||||||
DOCBOOK += keactrl.xml dhcp4-srv.xml dhcp6-srv.xml lease-expiration.xml logging.xml
|
DOCBOOK += keactrl.xml dhcp4-srv.xml dhcp6-srv.xml lease-expiration.xml logging.xml
|
||||||
DOCBOOK += ddns.xml hooks.xml hooks-class-cmds.xml hooks-ha.xml hooks-host-cache.xml
|
DOCBOOK += ddns.xml hooks.xml hooks-class-cmds.xml hooks-ha.xml hooks-host-cache.xml
|
||||||
DOCBOOK += hooks-lease-cmds.xml hooks-radius.xml hooks-stat-cmds.xml libdhcp.xml
|
DOCBOOK += hooks-lease-cmds.xml hooks-radius.xml hooks-stat-cmds.xml libdhcp.xml
|
||||||
DOCBOOK += lfc.xml stats.xml ctrl-channel.xml faq.xml classify.xml shell.xml agent.xml
|
DOCBOOK += lfc.xml stats.xml ctrl-channel.xml classify.xml shell.xml agent.xml
|
||||||
DOCBOOK += netconf.xml api.xml
|
DOCBOOK += netconf.xml api.xml
|
||||||
|
|
||||||
EXTRA_DIST = $(DOCBOOK)
|
EXTRA_DIST = $(DOCBOOK)
|
||||||
|
|||||||
@@ -1,138 +0,0 @@
|
|||||||
<!--
|
|
||||||
- Copyright (C) 2015-2018 Internet Systems Consortium, Inc. ("ISC")
|
|
||||||
-
|
|
||||||
- This Source Code Form is subject to the terms of the Mozilla Public
|
|
||||||
- License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
||||||
- file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
||||||
-->
|
|
||||||
|
|
||||||
<!-- Converted by db4-upgrade version 1.1 -->
|
|
||||||
<chapter xmlns="http://docbook.org/ns/docbook" version="5.0" xml:id="faq">
|
|
||||||
<title>Frequently Asked Questions</title>
|
|
||||||
|
|
||||||
<para>This chapter contains a number of frequently asked questions and
|
|
||||||
troubleshooting tips. It currently lacks content, but it is expected to grow
|
|
||||||
over time.</para>
|
|
||||||
|
|
||||||
<!-- Note: you may be tempted to put in questions here that concern current
|
|
||||||
missing features or known issues type of stuff. Please do not do that.
|
|
||||||
This section should only contain questions that will still be valid in
|
|
||||||
at least 2 years. If you have something short term, please consider putting
|
|
||||||
it in the known issues list. -->
|
|
||||||
|
|
||||||
<section xml:id="faq-generic">
|
|
||||||
<title>General Frequently Asked Questions</title>
|
|
||||||
|
|
||||||
<section xml:id="q1-generic">
|
|
||||||
<title>Where did the Kea name came from?</title>
|
|
||||||
|
|
||||||
<para>Kea is the name of a high mountain parrot living in New Zealand.
|
|
||||||
See this <uri xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://lists.isc.org/pipermail/kea-users/2014-October/000032.html">https://lists.isc.org/pipermail/kea-users/2014-October/000032.html</uri>
|
|
||||||
for an extended answer.</para>
|
|
||||||
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section xml:id="q2-generic">
|
|
||||||
<title>Feature X is not supported yet. When/if will it be available?</title>
|
|
||||||
|
|
||||||
<para>Kea is developed by a small team of engineers. Our resources are
|
|
||||||
limited, so we need to prioritize requests. The complexity of a new
|
|
||||||
feature (how difficult it is to implement a feature and how likely it
|
|
||||||
would break something that already works), amount of work required and
|
|
||||||
expected popularity (i.e., how many users would actually benefit from it)
|
|
||||||
are three leading factors. We sometimes also have contractual obligations.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para> Simply stating that you'd like feature X is useful. We try to
|
|
||||||
implement features that are actively requested first, but the reality
|
|
||||||
is that we have more requests than we can handle, so some of them must
|
|
||||||
be postponed, at least in the near future. So is your request likely to
|
|
||||||
be rejected? Not at all. You can do many things to greatly improve the
|
|
||||||
chances of your request being fulfilled. First, it helps to explain why you
|
|
||||||
need a feature. If your explanation is reasonable and there are likely
|
|
||||||
other users that would benefit from it, the chances for Kea developers
|
|
||||||
to put this task on a roadmap is better. Saying that you are willing
|
|
||||||
to participate in tests (e.g., test engineering drops when they become
|
|
||||||
available) is also helpful.</para>
|
|
||||||
|
|
||||||
<para>Another thing you can do to greatly improve the chances of a feature
|
|
||||||
to appear is to actually develop it on your own and submit a patch.
|
|
||||||
That's an avenue that people often forget about. Kea is open source
|
|
||||||
software and we do accept patches. There are certain requirements, like
|
|
||||||
code quality, comments, unit-tests, documentation, etc., but we have
|
|
||||||
accepted a significant number of patches in the past, so it's doable.
|
|
||||||
Accepted contributions range from minor documentation corrections to
|
|
||||||
significant new features, like support for a new database type. Before
|
|
||||||
considering writing and submitting a patch, make sure you read
|
|
||||||
the Contributor's Guide in the
|
|
||||||
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://git.kea.isc.org/~tester/kea/doxygen/">Kea Developer's Guide</link>.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>Kea is developed by ISC, which is a non-profit organization.
|
|
||||||
You may consider signing a development contract with us. In the past
|
|
||||||
we did implement certain features due to contractual obligations.
|
|
||||||
With additional funds we are able to put extra engineering efforts
|
|
||||||
into Kea development. We can reshuffle our schedule or add extra
|
|
||||||
hands to the team if needed. Please keep in mind that Kea is
|
|
||||||
open source software and its principle goal is to provide a good DHCP
|
|
||||||
solution that can be used by everyone. In other words, we may
|
|
||||||
refuse a contract that would tie the solution to specific proprietary
|
|
||||||
technology or make it unusable for other users. Also, we strive to
|
|
||||||
make Kea a reference implementation, so if your proposal significantly
|
|
||||||
violates a RFC, we may have a problem with that. Nevertheless, please
|
|
||||||
talk to us and we may be able to find a solution.</para>
|
|
||||||
|
|
||||||
<para>Finally, Kea has a <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://kea.isc.org/roadmap">public
|
|
||||||
roadmap</link>, with releases happening several times each year. We tend
|
|
||||||
to not modify plans for the current milestone, unless there are very good
|
|
||||||
reasons to do so. Therefore "I'd like a feature X in 6 months" is much
|
|
||||||
better received than "I'd like a feature X now".</para>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section xml:id="faq-dhcp4">
|
|
||||||
<title>Frequently Asked Questions about DHCPv4</title>
|
|
||||||
|
|
||||||
<section iq="q1-dhcp4">
|
|
||||||
<title>I set up a firewall, but the Kea server still receives the traffic. Why?</title>
|
|
||||||
|
|
||||||
<para>Any DHCPv4 server must be able to receive from and send traffic to
|
|
||||||
hosts that don't have an IPv4 address assigned yet. That is typically not
|
|
||||||
possible with regular UDP sockets, therefore the Kea DHCPv4 server uses raw
|
|
||||||
sockets by default. Raw sockets mean that the incoming packets are received
|
|
||||||
as raw Ethernet frames, thus bypassing the whole kernel IP stack, including
|
|
||||||
any firewalling rules your kernel may provide.</para>
|
|
||||||
|
|
||||||
<para>If you do not want the server to use raw sockets, it is possible to
|
|
||||||
configure the Kea DHCPv4 server to use UDP sockets instead. See <command>dhcp-socket-type</command>
|
|
||||||
described in <xref linkend="dhcp4-interface-configuration"/>. However,
|
|
||||||
using UDP sockets has certain limitations. In particular, they may not allow
|
|
||||||
for sending responses directly to clients without IPv4 addresses assigned.
|
|
||||||
That's ok, if all your traffic is coming through relay agents.</para>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
</section> <!-- end of DHCPv4 FAQ section -->
|
|
||||||
|
|
||||||
<section xml:id="faq-dhcp6">
|
|
||||||
<title>Frequently Asked Questions about DHCPv6</title>
|
|
||||||
|
|
||||||
<section iq="q1-dhcp6">
|
|
||||||
<title>Kea DHCPv6 doesn't seem to get incoming traffic. I checked with tcpdump (or other traffic
|
|
||||||
capture software) that the incoming traffic is reaching the box. What's wrong?</title>
|
|
||||||
|
|
||||||
<para>Please check whether your OS has any IPv6 filtering rules. Many
|
|
||||||
operating systems are shipped with firewalls that discard incoming IPv6
|
|
||||||
traffic by default. In particular, many Linux distributions do that. Please
|
|
||||||
check the output of the following command:
|
|
||||||
<screen>
|
|
||||||
# <userinput>ip6tables -L -n</userinput></screen>
|
|
||||||
One common mistake in this area is to use <command>iptables</command> tool,
|
|
||||||
which lists IPv4 firewall rules only.
|
|
||||||
</para>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
</section> <!-- end of DHCPv6 FAQ section -->
|
|
||||||
|
|
||||||
|
|
||||||
</chapter>
|
|
||||||
@@ -92,9 +92,6 @@
|
|||||||
|
|
||||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="netconf.xml"/>
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="netconf.xml"/>
|
||||||
|
|
||||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
||||||
href="faq.xml"/>
|
|
||||||
|
|
||||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="api.xml"/>
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="api.xml"/>
|
||||||
|
|
||||||
<appendix xml:id="acknowledgments">
|
<appendix xml:id="acknowledgments">
|
||||||
|
|||||||
Reference in New Issue
Block a user