Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2019-11-25T17:37:11Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/804CB: doc never says clearly how to configure server-tag on a server2019-11-25T17:37:11ZTomek MrugalskiCB: doc never says clearly how to configure server-tag on a serverPerhaps I missed it, but I couldn't find in the docs how to tell Kea instance what is its server tag.
I finally managed to get it by looking at the code.
The doc/examples/kea{4,6}/config-backend.json and Kea ARM should be updated.Perhaps I missed it, but I couldn't find in the docs how to tell Kea instance what is its server tag.
I finally managed to get it by looking at the code.
The doc/examples/kea{4,6}/config-backend.json and Kea ARM should be updated.Kea1.6-finalFrancis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/150[ISC-support #13437] Have vendor option processing made accessible to classif...2019-09-13T13:17:38ZCathy Almond[ISC-support #13437] Have vendor option processing made accessible to classification for subnet allocationThere's a chicken-and-egg problem. Option 43 syntax is vendor specific, so Kea allows adding option definitions to client class, so you can have vendor dependent parsing. However, to use this the packet needs to be classified first. But...There's a chicken-and-egg problem. Option 43 syntax is vendor specific, so Kea allows adding option definitions to client class, so you can have vendor dependent parsing. However, to use this the packet needs to be classified first. But what if you want to use values in option 43 suboptions to assist with classification? Parsing them using "substring" relies on all client packets having the same vendor options/suboptions in the same order - this can't be guaranteed.
---
This feature request originated in Support ticket https://support.isc.org/Ticket/Display.html?id=13437
The use case from this production environment is from the same environment as presented in https://gitlab.isc.org/isc-projects/kea/issues/149.
In this instance, additional classification is desired, based on the vendor options.
A workaround was created adding further processing to an already-existing custom hook with callout at pkt4_receive.
The processing flow within this hook was extended to add something along the lines of:
```
Pkt4Ptr pkt;
callout_handle->getArgument("query4", pkt);
OptionPtr option43 = pkt->getOption(43);
OptionPtr option2 = option43->getOption(2);
if (option2) {
std::string payload(option2->getData().begin(), option2->getData().end());
if ((payload == "MTA") || (payload == "EMTA")) {
pkt->addClass("MTA");
}
}
```
(Note that the above syntax is example-only and not tested in production)Kea1.6-finalTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/841Bump up library version numbers for the Kea 1.6.0 final release2019-09-11T10:32:08ZMarcin SiodelskiBump up library version numbers for the Kea 1.6.0 final releaseSee the https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html for the guidelines about updating the version numbers.See the https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html for the guidelines about updating the version numbers.Kea1.6-finalMarcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/853MySQL 8.0.17, schema create script fails because "array" became a MySQL re...2019-09-04T08:27:50ZThomas MarkwalderMySQL 8.0.17, schema create script fails because "array" became a MySQL reserved worddhcpdb_drop.mysql fails with a syntax error on line 875 ... "near 'array TINYINT(1)...". As of MySQL 8.0.17, "array" is a reserved word. We'll have to rename the column.dhcpdb_drop.mysql fails with a syntax error on line 875 ... "near 'array TINYINT(1)...". As of MySQL 8.0.17, "array" is a reserved word. We'll have to rename the column.Kea1.6-finalThomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/840unit test cb_ctl_dhcp_unittest.cc fails and crashes on freebsd2019-09-04T08:27:48ZMichal Nowikowskiunit test cb_ctl_dhcp_unittest.cc fails and crashes on freebsdMachine: freebsd113-64
Log fragment:
```
cb_ctl_dhcp_unittest.cc:457: Failure
Value of: found_network
Actual: false
Expected: true
Assertion failed: (px != 0), function operator->, file /usr/local/include/boost/smart_ptr/shared_ptr.hp...Machine: freebsd113-64
Log fragment:
```
cb_ctl_dhcp_unittest.cc:457: Failure
Value of: found_network
Actual: false
Expected: true
Assertion failed: (px != 0), function operator->, file /usr/local/include/boost/smart_ptr/shared_ptr.hpp, line 734.
```
Full logs:
- https://jenkins.isc.org/job/kea-master-ut-basic/531/parsed_console/
- https://jenkins.isc.org/job/kea-1.6/job/ut-basic/532/execution/node/197/log/?consoleFullKea1.6-finalRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/839Rebuild parsers with recent flex2019-08-31T12:59:01ZTomek MrugalskiRebuild parsers with recent flexCompilation warnings in src/lib/eval due to old flex being used.Compilation warnings in src/lib/eval due to old flex being used.Kea1.6-finalTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/706default paths for lease files (among other things) have changed recently, th...2019-08-29T19:14:49ZThomas Markwalderdefault paths for lease files (among other things) have changed recently, this needs to be documented for usersRecent issue(s) changed the default paths for many items, including lease files. This represents an upgrade issue for users and needs to be documented in a HIGHLY visible place are we will get endless support issues over this. There ne...Recent issue(s) changed the default paths for many items, including lease files. This represents an upgrade issue for users and needs to be documented in a HIGHLY visible place are we will get endless support issues over this. There needs to be an Upgrading to Kea 1.6.0 section in the release notes and possibly the ARM.Kea1.6-finalhttps://gitlab.isc.org/isc-projects/kea/-/issues/837Config rename: all-keys.json and all-keys-netconf.json2019-08-29T12:41:13ZTomek MrugalskiConfig rename: all-keys.json and all-keys-netconf.jsonThe configs are called: all-keys-current.json (should be all-keys.json) and all-keys-stable.json (should be all-keys-netconf.json).
Should be a trivial rename.The configs are called: all-keys-current.json (should be all-keys.json) and all-keys-stable.json (should be all-keys-netconf.json).
Should be a trivial rename.Kea1.6-finalTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/852nits: Logging section in ARM mentions kea-dhcp4.options logger twice; User Ch...2019-08-26T12:16:44ZTomek Mrugalskinits: Logging section in ARM mentions kea-dhcp4.options logger twice; User Check name is inconsistent in Hooks Libraries listVery tiny things to fix. We mention kea-dhcp4.options twice, but kea-dhcp6.options is not mentioned. Also, all the other hooks libraries names are listed in the Available Hooks Libraries table, but User Check is just listed as user_chk.Very tiny things to fix. We mention kea-dhcp4.options twice, but kea-dhcp6.options is not mentioned. Also, all the other hooks libraries names are listed in the Available Hooks Libraries table, but User Check is just listed as user_chk.Kea1.6-finalhttps://gitlab.isc.org/isc-projects/kea/-/issues/831Proposed new SW Support and Release Versioning Policy2019-08-20T19:06:53ZVicky Riskvicky@isc.orgProposed new SW Support and Release Versioning PolicyWith the release of Kea 1.6 we plan to change the release model. We need to update our software support and versioning policy accordingly. I will also publish a short blog or email to bind-users or both on the topic, once we are all clea...With the release of Kea 1.6 we plan to change the release model. We need to update our software support and versioning policy accordingly. I will also publish a short blog or email to bind-users or both on the topic, once we are all clear on what the changes are.
Below is proposed text for the new Software Support and Version Numbering policy (https://kb.isc.org/docs/aa-00896) for review. It is intended to be as much like the BIND statement as applicable.
One thing we have not addressed - it says we won't add new features to existing stable versions, but what about new hook libraries? IMHO that is a grey area. If a customer wanted us to create a new hook library, I am assuming we probably would create it on/with the current stable version, not the development version.
We might need some sort of general statement about hook libraries, versioning and support.
===================
**Kea**
With the release of Kea 1.6.0, we are changing our release model for Kea.
We will have two types of major Kea versions: Development and Stable. At any given time, we should have at least two options available, one or more Stable and one Development release.
**Development versions**
We release development versions off of the current working (master) branch. These will be the odd-numbered minor versions, starting from Kea 1.7.0.
There is no fixed schedule to development releases; new versions will be made available as new features or changes become ready for field testing. Maintenance releases on development branches will introduce new and updated features and may not be backward-compatible with their immediate predecessor. Development versions of Kea are suitable for those interested in experimenting with and providing feedback to ISC, but are not recommended for production use. There will be no alpha/beta/release candidate versions of development versions, and it may sometimes happen that a recently-released minor version is superseded very quickly in order to address a flaw. We may not issue patch releases for development versions with security bugs, at our discretion.
Development versions will be maintained until the next Stable version is created, at which time we will begin a new development branch (with the next odd number). We estimate development versions will mature into stable versions in less than a year, but this is a prediction, not a promise.
**Stable versions**
Beginning with Kea 1.6, we plan stabilize all the even-numbered minor versions for production use – for example, Kea 1.6 and Kea 1.8 will be stable versions. Each of these branches will have a series of maintenance releases, such as Kea 1.6.1, 1.6.2, etc. Maintenance releases on a Stable version will include bug fixes only, to maximize stability.
Stable versions of Kea are fully supported for 6 months after the next stable version is released. This means you should have ample time to migrate to a new stable version before the older one is EOL. We do not yet have ‘Extended Support’ versions of Kea. We still have a very high rate of new feature development and are not yet ready for a very long-lived stable branch. We expect to be able to update the ISC Kea packages the same day we post the tarballs.
* Kea 1.3 went to EOL in December 2018
* Kea 1.4 will be supported until August 2019 (or until we release Kea 1.6)
* Kea 1.5 will be supported until we release Kea 1.8.
* Kea 1.6 will be a stable version, supported for 6 months after we release Kea 1.8, or until we release Kea 2.0, whichever is sooner.
* Kea 1.7 will be a development version supported until we release Kea 1.9
* Kea 1.8 will be the next stable version after 1.6
———————
**OLD Policy (Currently published policy)** https://kb.isc.org/docs/aa-00896
All Kea releases to date include new features and are considered development releases. We will continue doing this to keep up with the pace of new development until further notice. Currently, we are issuing updates every 4-6 months, and there is no such thing as a maintenance-only release. ISC offers support for the current, and immediate prior, regularly-released versions of Kea. As the product matures, we plan on supporting both maintenance and development branches.
* Kea 1.3 went to EOL in December 2018
* Kea 1.4 will be supported until July 2019 (or until we release Kea 1.6)
* Kea 1.5 will be supported until December 2019 (or until we release Kea 1.7)
Other General Policy Guidelines
* Standard support terms do not apply to developmental releases, the Supported Preview edition, or alpha, beta, and Release Candidates (RCs). These are typically shorter-lived releases.
* We reserve the right to change our version numbering for Kea.
* We also reserve the right, based on these changes, to include some minor features in point releases (e.g. 9.8.1) for BIND 9 and ISC DHCP.Kea1.6-finalTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/810sphinx documentation generates invalid json data2019-08-16T18:05:17ZRazvan Becheriusphinx documentation generates invalid json datathere are several documents that generate invalid json datathere are several documents that generate invalid json dataKea1.6-finalTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/659How configure client-class for pools in db?2019-08-16T16:36:56ZGhost UserHow configure client-class for pools in db?For correct working HA it need to configure client-class for each pool as in documentaion:
```
"pools": [
{
"pool": "192.0.3.100 - 192.0.3.150",
"client-class": "HA_server1"
},
{
"pool": "192.0.3.200 - 19...For correct working HA it need to configure client-class for each pool as in documentaion:
```
"pools": [
{
"pool": "192.0.3.100 - 192.0.3.150",
"client-class": "HA_server1"
},
{
"pool": "192.0.3.200 - 192.0.3.250",
"client-class": "HA_server2"
}
],
```
But DB scheme (tables dhcp4_pool and dhcp6_pool) has not column for client-class:
```
CREATE TABLE `dhcp4_pool` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`start_address` int(10) unsigned NOT NULL,
`end_address` int(10) unsigned NOT NULL,
`subnet_id` int(10) unsigned NOT NULL,
`modification_ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
KEY `key_dhcp4_pool_modification_ts` (`modification_ts`),
KEY `fk_dhcp4_pool_subnet_id` (`subnet_id`),
CONSTRAINT `fk_dhcp4_pool_subnet_id` FOREIGN KEY (`subnet_id`) REFERENCES `dhcp4_subnet` (`subnet_id`) ON DELETE CASCADE ON UPDATE CASCADE
)
```Kea1.6-finalTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/532Update https://kb.isc.org/docs/kea-performance-optimization with info from GL...2019-08-16T16:14:52ZCathy AlmondUpdate https://kb.isc.org/docs/kea-performance-optimization with info from GL #509#509 is another potential performance-improving option - we should include it in the performance considerations KB article [https://kb.isc.org/docs/kea-performance-optimization](https://kb.isc.org/docs/kea-performance-optimization)#509 is another potential performance-improving option - we should include it in the performance considerations KB article [https://kb.isc.org/docs/kea-performance-optimization](https://kb.isc.org/docs/kea-performance-optimization)Kea1.6-finalVicky Riskvicky@isc.orgVicky Riskvicky@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/838sphinx fails sometime with RuntimeError: maximum recursion depth exceeded2019-08-16T12:31:06ZMichal Nowikowskisphinx fails sometime with RuntimeError: maximum recursion depth exceededKea1.6-finalMichal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/654perfdhcp does not print all the RTT stats on no received packets2019-08-16T10:15:18ZAndrei Pavelandrei@isc.orgperfdhcp does not print all the RTT stats on no received packetsWhen there are no received packets, an exception is thrown in `ExchangeStats::getAvgDelay()` which results in `min delay`, `avg delay` displayed like so:
```
min delay: inf ms
avg delay: Delay summary unavailable! No packets received.
``...When there are no received packets, an exception is thrown in `ExchangeStats::getAvgDelay()` which results in `min delay`, `avg delay` displayed like so:
```
min delay: inf ms
avg delay: Delay summary unavailable! No packets received.
```
`max delay`, `std deviation`, `collected packets` are missing.
Either display all or display none for easier automated parsing. I prefer displaying all. In that case, delays could get zero or inf values as they are impossible values. Or sure, display an error message.Kea1.6-finalWlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/625Kea fails to start with log4cplus compiled without implicit initialization2019-08-15T20:29:59ZGhost UserKea fails to start with log4cplus compiled without implicit initialization**Describe the bug**
Log4cplus introduced new build option to disable implicit initialization during startup in 2.0.4 (https://sourceforge.net/p/log4cplus/news/2019/04/v204/):
```
--disable-implicit-initialization
```
With this option ...**Describe the bug**
Log4cplus introduced new build option to disable implicit initialization during startup in 2.0.4 (https://sourceforge.net/p/log4cplus/news/2019/04/v204/):
```
--disable-implicit-initialization
```
With this option enabled Kea's binaries won't start:
```
# ./kea-dhcp4 -c /etc/kea/kea-dhcp4.conf
kea-dhcp4: Fatal error during start up: log4cplus is not initialized and implicit initialization is turned off
```
Particularly latest log4cplus package in Alpine Linux is compiled with this option.
As a result one can't use Kea with Alpine without building it from sources (https://bugs.alpinelinux.org/issues/10480).
**To Reproduce**
Steps to reproduce the behavior:
1. Configure and build log4cplus version 2.0.4 with `--disable-implicit-initialization` option;
2. Build Kea using that log4cplus library;
2. Try to start Kea server
```
# ./kea-dhcp4 -c /etc/kea/kea-dhcp4.conf
kea-dhcp4: Fatal error during start up: log4cplus is not initialized and implicit initialization is turned off
```
**Expected behavior**
```
# ./kea-dhcp4 -c /etc/kea/kea-dhcp4.conf
INFO [kea-dhcp4.dhcp4/14122] DHCP4_STARTING Kea DHCPv4 server version 1.5.0-git starting
```
**Environment:**
- Kea version: 1.5.0;
- OS: Any;
- Log4cplus with --disable-implicit-initialization;
**Describe the solution you'd like**
Explicitly initialize log4cplus in Kea.Kea1.6-finalTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/496Correct manual section: "relayed traffic in shared networks"2019-08-15T19:24:22ZMarcin SiodelskiCorrect manual section: "relayed traffic in shared networks"The "Local and relayed traffic in shared networks" implies that using different "relay" values for different subnets within a shared network will cause the server to prefer the subnets with matching selector. In fact, the relay case is n...The "Local and relayed traffic in shared networks" implies that using different "relay" values for different subnets within a shared network will cause the server to prefer the subnets with matching selector. In fact, the relay case is no different than selection via interface name (direct traffic). The server will initially select the subnet indicated by the relay, but will later change it to a subnet that was most recently used. The documentation must be corrected in that regard.Kea1.6-finalhttps://gitlab.isc.org/isc-projects/kea/-/issues/761Extend use of quoting mechanism for circuit-id to allow string initializers f...2019-08-15T16:08:56ZThomas MarkwalderExtend use of quoting mechanism for circuit-id to allow string initializers for binary optionsWe currently support setting "circuit-id" in host reservations by embedding a text string in sinqle-quotes:
```
"circuit-id": "'charter950'",
```
Allowing this syntax for any binary option would be very convenient for users:
```...We currently support setting "circuit-id" in host reservations by embedding a text string in sinqle-quotes:
```
"circuit-id": "'charter950'",
```
Allowing this syntax for any binary option would be very convenient for users:
```
{
# Supply option 43,sub option 1 string data
"name": "the-url",
"code": 1,
"data": "'https://example.this-is-a-long-url.imagine-it-as-hex-sting.com'",
"space": "example-space"
}
```
This allows users to readily support options that carry string data but can be empty. See #719 and #750.Kea1.6-finalTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/727Reservation client-classes too late/later as documented for depending classes2019-08-15T15:09:28ZChrisReservation client-classes too late/later as documented for depending classes**Describe the bug**
Client classes that are applied from a reservation are added too late to `test` against except for `only-if-required` classes, even when also depending on `KNOWN` (despite of what the NOTE in [Kea Guide 8.3.6](https...**Describe the bug**
Client classes that are applied from a reservation are added too late to `test` against except for `only-if-required` classes, even when also depending on `KNOWN` (despite of what the NOTE in [Kea Guide 8.3.6](https://ftp.isc.org/isc/kea/1.5.0/doc/kea-guide.html#reservation4-client-classes) says).
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea dhcpv4 with config:
```json[kea-reservation.log](/uploads/282012d6ad4a49c58157219f47d511c7/kea-reservation.log)[kea-reservation.log](/uploads/8b88984ba62689b6768b146dd13dbb7f/kea-reservation.log)
"client-classes": [
{
"name": "pxe"
},
{
"name": "ipxe",
"test": "member('KNOWN') and (option[77].hex == 'iPXE') and member('pxe')",
"boot-file-name": "http://ipxe.example.com/menu.php"
},
{
"name": "not_ipxe",
"next-server": "192.168.100.6",
"boot-file-name": "undionly.kpxe"
}
]
```
MySQL hosts reservation:
```
+--------------+----------+----------------------+
| ipv4_address | hostname | dhcp4_client_classes |
+--------------+----------+----------------------+
| 167837702 | pxetest | pxe,testing |
+--------------+----------+----------------------+
```
2. Logging set kea-dhcp4 to DEBUG, debuglevel 55
3. Client "pxetest" is booted with iPXE
4. Client "pxetest" does not get boot-file-name/added to class `pxe` in time to eval true on `ipxe`
5. See kea-reservation.log for details
(6. See extremely little logging for reservation classes - only reason I know they were applied at all (not even the final list mentions `pxe`!) was the warning about `testing` after lease assignment)
**Expected behavior**
The server is supposed to add client-classes at reservation lookup together with `KNOWN`, so classes that depend on `KNOWN` and a reserved class are evaluated as true, as described in mentioned documentation.
**Environment:**
- Kea version: 1.5.0 from Ubuntu 19.04 repositories (manually downloaded)
- OS: Ubuntu 18.04 x64
- Which features were compiled in:
- MySQL 7.0, library 5.7.26
- PostgreSQL backend 5.0, library 100009 (not used)
- Memfile backend 2.1 (not used)
- If/which hooks where loaded in:
- lease commands
- HA
**Additional Information**
Current workaround is to load classes depending on reserved classes only-if-required, which means adding a `require-client-classes` to all subnets/shared networks as appropriate (in my case 97% of subnets) adding a lot of configuration overhead with the possibility of very long lists in complicating setups, which kinda defeats the purpose of client classes in my mind.
**Log Debuglevel 55**
```
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.dhcpsrv/7390] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 192.168.100.0/24 for packet received by matching address 192.168.100.1
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.packets/7390] DHCP4_SUBNET_SELECTED [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: the subnet with ID 16 was selected for client assignments
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.packets/7390] DHCP4_SUBNET_DATA [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: the selected subnet details: 192.168.100.0/24
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.hosts/7390] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=52C625F534AC
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.hosts/7390] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=52C625F534AC, found 0 host(s)
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.dhcp4/7390] DHCP4_CLASS_ASSIGNED [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: client packet has been assigned to the following class(es): KNOWN
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_MEMBER Checking membership of 'KNOWN', pushing result 'true'
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_OPTION Pushing option 77 with value 0x69505845
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_STRING Pushing text string 'iPXE'
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_EQUAL Popping 0x69505845 and 0x69505845 pushing result 'true'
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_AND Popping 'true' and 'true' pushing 'true'
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_MEMBER Checking membership of 'pxe', pushing result 'false'
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_AND Popping 'false' and 'true' pushing 'false'
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.options/7390] EVAL_RESULT Expression ipxe evaluated to 0
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_OPTION Pushing option 77 with value 0x69505845
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_STRING Pushing text string 'iPXE'
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_EQUAL Popping 0x69505845 and 0x69505845 pushing result 'true'
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_NOT Popping 'true' pushing 'false'
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_MEMBER Checking membership of 'pxe', pushing result 'false'
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_AND Popping 'false' and 'false' pushing 'false'
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_MEMBER Checking membership of 'KNOWN', pushing result 'true'
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_AND Popping 'true' and 'false' pushing 'false'
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.options/7390] EVAL_RESULT Expression not_ipxe evaluated to 0
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.dhcp4/7390] DHCP4_CLASS_ASSIGNED [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: client packet has been assigned to the following class(es): HA_ns1-kea, ALL, VENDOR_CLASS_PXEClient:Arch:00000:UNDI:002001, deny_snom_dap_pap2t, KNOWN
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.ddns/7390] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: processing client's Hostname option
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.dhcpsrv/7390] DHCPSRV_MYSQL_GET_CLIENTID obtaining IPv4 leases for client ID 01:52:c6:25:f5:34:ac
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.hosts/7390] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 162 and IPv4 address 10.1.0.6
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.hosts/7390] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 10.1.0.6
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.hosts/7390] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 10.1.0.6, found 0 host(s)
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.hosts/7390] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 162 and address 10.1.0.6
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.hosts/7390] HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_ADDRESS4 trying alternate sources for host using subnet id 162 and address 10.1.0.6
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.dhcpsrv/7390] DHCPSRV_MYSQL_GET_ADDR4 obtaining IPv4 lease for address 10.1.0.6
2019-07-08 12:15:54.798 DEBUG [kea-dhcp4.alloc-engine/7390] ALLOC_ENGINE_V4_REQUEST_EXTEND_LEASE [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: extending lifetime of the lease for address 10.1.0.6
2019-07-08 12:15:54.798 DEBUG [kea-dhcp4.dhcpsrv/7390] DHCPSRV_MYSQL_UPDATE_ADDR4 updating IPv4 lease for address 10.1.0.6
2019-07-08 12:15:54.861 DEBUG [kea-dhcp4.packets/7390] DHCP4_SUBNET_DYNAMICALLY_CHANGED [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: changed selected subnet 192.168.100.0/24 to subnet 10.1.0.0/20 from shared network servers for client assignments
2019-07-08 12:15:54.861 INFO [kea-dhcp4.leases/7390] DHCP4_LEASE_ALLOC [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: lease 10.1.0.6 has been allocated
2019-07-08 12:15:54.861 DEBUG [kea-dhcp4.dhcp4/7390] DHCP4_CLASS_UNCONFIGURED [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: client packet belongs to an unconfigured class: testing
2019-07-08 12:15:54.861 DEBUG [kea-dhcp4.callouts/7390] HOOKS_CALLOUTS_BEGIN begin all callouts for hook leases4_committed
2019-07-08 12:15:54.861 DEBUG [kea-dhcp4.callouts/7390] HOOKS_CALLOUT_CALLED hooks library with index 2 has called a callout on hook leases4_committed that has address 0x7efe0edcb150 (callout duration: 0.123 ms)
2019-07-08 12:15:54.861 DEBUG [kea-dhcp4.callouts/7390] HOOKS_CALLOUTS_COMPLETE completed callouts for hook leases4_committed (total callouts duration: 0.123 ms)
2019-07-08 12:15:54.861 DEBUG [kea-dhcp4.hooks/7390] DHCP4_HOOK_LEASES4_COMMITTED_PARK [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: packet is parked, because a callout set the next step to PARK
```
**Contacting you**
Gitlab/hubKea1.6-finalFrancis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/721kea-shell is not working when installed from a debian package2019-08-15T15:07:07ZMichal Nowikowskikea-shell is not working when installed from a debian packageThe problem is with hardcoded path for importing of kea_conn.
In kea-shell, this should be removed:
```python
sys.path.append('@PKGPYTHONDIR@')
```
and this:
```python
from kea_conn import CARequest # CAResponse
```
should be change...The problem is with hardcoded path for importing of kea_conn.
In kea-shell, this should be removed:
```python
sys.path.append('@PKGPYTHONDIR@')
```
and this:
```python
from kea_conn import CARequest # CAResponse
```
should be changed to:
```python
from kea.kea_conn import CARequest # CAResponse
```Kea1.6-finalTomek MrugalskiTomek Mrugalski