Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2019-03-06T20:25:35Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/478Improve error message: "Database access parameter 'type' does not specify a s...2019-03-06T20:25:35ZCathy AlmondImprove error message: "Database access parameter 'type' does not specify a supported database backend:mysql"---
name: Improve error message: "Database access parameter 'type' does not specify a supported database backend:mysql"
about: Please make it clearer why this error is being emitted. The 'type' is a valid configuration option. The prob...---
name: Improve error message: "Database access parameter 'type' does not specify a supported database backend:mysql"
about: Please make it clearer why this error is being emitted. The 'type' is a valid configuration option. The problem is that the build does not include support for mysql back-end.
---
These error messages don't explain well what the problem is and where to look to fix it:
> root@debian:/opt/kea-1.5.0# 2019-02-18 17:26:12.746 ERROR [kea-dhcp4.dhcp4/51240] DHCP4_CONFIG_LOAD_FAIL configuration error using file: /usr/local/etc/kea/kea-dhcp4.conf, reason: Unable to open database: Database access parameter 'type' does not specify a supported database backend:mysql
> 2019-02-18 17:26:12.746 ERROR [kea-dhcp4.dhcp4/51240] DHCP4_INIT_FAIL failed to initialize Kea server: configuration error using file '/usr/local/etc/kea/kea-dhcp4.conf': Unable to open database: Database access parameter 'type' does not specify a supported database backend:mysql
A better message would be something like:
"Unable to open database: The Kea server has not been built with support for database type: mysql"
See [#14213](https://support.isc.org/Ticket/Display.html?id=14213)Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/474RADIUS with shared networks2019-05-15T12:50:03ZTomek MrugalskiRADIUS with shared networksWhen RADIUS was implemented, we didn't have shared networks support. As a result, there was a mechanism designed (subnet-reselect) to do something a bit similar to shared networks.
We need to look at the code and see:
- what is needed t...When RADIUS was implemented, we didn't have shared networks support. As a result, there was a mechanism designed (subnet-reselect) to do something a bit similar to shared networks.
We need to look at the code and see:
- what is needed to make RADIUS work with shared network
- what the limitations would be
RADIUS has some substantial limitations as a database-like system, but the basic assumption that it can return attributes that are mapped to client classes should be viable.
#403 has a discussion about current (1.5) code and its limitations.Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/465Add subnet4-update and subnet6-update commands to subnet-cmds hook [ISC-suppo...2019-04-19T11:25:18ZVicky Riskvicky@isc.orgAdd subnet4-update and subnet6-update commands to subnet-cmds hook [ISC-support #14130]In order to update an existing subnet, you (currently) have to first delete it and then add it.
When making a small change to a large number of subnets, this can create excessive amount of traffic.
Could we please have additional comman...In order to update an existing subnet, you (currently) have to first delete it and then add it.
When making a small change to a large number of subnets, this can create excessive amount of traffic.
Could we please have additional commands to update an existing subnet?
This was part of the original design, but we didn't implement it at the time (likely ran out of time)
https://gitlab.isc.org/isc-projects/kea/wikis/designs/commands#24-subnets-management
S.7. Kea MAY support the #FF0000 subnet4-update command.
S.8. Kea MAY support the #FF0000 subnet6-update command.
From the wiki:
Those two commands allow making changes to an existing subnet: changing prefix, prefix length, T1, T2, preferred lifetime, valid lifetime timers, allowed client classes, subnet specific options, and subnet-id values. It also allows modifying pools.
Kea1.6Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/425Provide binary packages of Kea open source2019-07-22T10:51:05ZVicky Riskvicky@isc.orgProvide binary packages of Kea open sourceMany users prefer to get an already-compiled application to building it themselves. Kea is not kept up to date in some of the operating system distributions and it would be very convenient for users if ISC would provide an official repo ...Many users prefer to get an already-compiled application to building it themselves. Kea is not kept up to date in some of the operating system distributions and it would be very convenient for users if ISC would provide an official repo with packages for at least, CentOS/EPL and Debian.
Part of the problem is incorporating the dependencies on other open source, which obviously complicates the job of producing a package.
Below is the link to the Doodle poll we did earlier, which showed that the most popular OSes for Kea are CentOS, Ubuntu and Debian, in that order. The poll didn't include RedHat when we launched it, so that may be undercounted or counted as CentOS.
https://doodle.com/poll/g2ff9rwpdzxwsvhhKea1.6-beta2Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/365Automatically calculate the values for options 58 and 592019-04-26T15:37:42ZCathy AlmondAutomatically calculate the values for options 58 and 59---
name: Automatically calculate the values for options 58 and 59
about: This is a request to have it be possible for Kea to calculate and send the values for renew-timer and rebind-timer (T1 and T2) using 0.5 * duration_of_lease, and ...---
name: Automatically calculate the values for options 58 and 59
about: This is a request to have it be possible for Kea to calculate and send the values for renew-timer and rebind-timer (T1 and T2) using 0.5 * duration_of_lease, and 0.875 * duration_of_lease, respectively
---
**Some initial questions**
This is a request from a customer, per ticket [#13977](https://support.isc.org/Ticket/Display.html?id=13977)
At the moment, ISC Kea defaults to not sending T1 and T2, although they can be specified explicitly using optional renew-timer and rebind-timer. What is being requested is another option in which we ask Kea to automate this - i.e. to calculate them based on the lease time being offered using the default behaviour that clients should be adopting as noted above.
The reason for requesting this is that:
a) Other DHCP servers (e.g. Nominum) do this by default (even though ISC DHCP does not)
b) It is a potential mitigation for clients that are not fully RFC-compliant
**Describe the solution you'd like**
In it's simplest form, a blanket option to request that Kea calculate the timers and send them for any lease offer, calculations being appropriate to that specific offer.
More flexibility might be appreciated however - for example being able to set this per subnet, pool or shared-network to override a global setting which might be different.
For full flexibility, the option could perhaps also have an alternative syntax in which it accepts the percentages as an override to the default of .5 and .875 - although this might be overkill - would anyone want these to be different? (Perhaps leading up to a pool/servers migration maybe?)
**Describe alternatives you've considered**
Currently, the only way to ensure that ISC Kea sends the values of T1 and T2 that are wanted is to configure them explicitly, it's not possible to have them sent automatically
**Additional context**
Note that this may be regarded as a compatibility issue by anyone migrating to ISC Kea from another DHCP server implementation that does automatically send T1 and T2.Kea1.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/359Possible bug in kea 1.5.0 - problems with paths for logger_lockfile and kea-d...2019-07-22T10:51:51ZGhost UserPossible bug in kea 1.5.0 - problems with paths for logger_lockfile and kea-dhcp{4,6}.log.lockMost of my original bug report below is focusing on a non-problem, concerning the kea subdir, but as it still contains some valid questions I will leave it unedited. Please read my latest comment.
---
name: No longer possible to specify...Most of my original bug report below is focusing on a non-problem, concerning the kea subdir, but as it still contains some valid questions I will leave it unedited. Please read my latest comment.
---
name: No longer possible to specify exact pid file dir
about: a kea subdir is now always present
---
**Describe the bug**
It does not seem possible to specify an exact pid file dir like /run or /var/run using the --localstatedir= option when running configure as described here: https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#dhcp4-start-stop
If the localstatedir is set to i.e --localstatedir=/home/builder/test/run the resulting directory tree looks like this:
```
[builder@centbuild test]$ tree run/
run/
├── kea
│ ├── kea-dhcp6.kea-dhcp6.pid
│ ├── kea-dhcp6-serverid
│ └── kea-leases6.csv
├── log
└── run
└── kea
└── logger_lockfile
```
The kea subdir is not specified with the --localstatedir option, where does it come from and how to disable it?
And why is the extra run/kea/log subdirs created here? According to documentation the ```logger_lockfile``` should be placed in /var/run/kea. The location seems to be determined by localstatedir, but again with the kea subdir seemingly hardcoded in.
On CentOS the problem manifests itself post installation when trying to start daemons and with the kea subdir not present. A possible workaround is to hardcode KEA_PIDFILE_DIR variable in to the systemd units, but as stated in the documentation, this primarily for testing purposes.
I ran the build both with and without autoreconf --verbose --force --install. The results are not exactly the same.
Building the source without autoreconf the subdir tree looked like this:
```
[builder@centbuild run]$ tree .
.
├── kea
│ ├── kea-dhcp6-serverid
│ └── kea-leases6.csv
├── log
│ ├── kea-dhcp6.log
│ └── kea-dhcp6.log.lock
└── run
└── kea
└── logger_lockfile
```
With log files now placed in log subdir inside localstatedir.
**To Reproduce**
Steps to reproduce the behavior:
1. ./configure --prefix=/home/builder/test --localstatedir=/home/builder/test/run --disable-dependency-tracking --disable-rpath --disable-silent-rules --disable-static --enable-debug --enable-shell --with-mysql --with-log4cplus --with-openssl --with-pgsql --with-gnu-ld && make && make install
2. Post installation observe that pid file is created in /home/builder/test/run/kea subdir
3. autoreconf --verbose --force --install && /configure --prefix=/home/builder/test --localstatedir=/home/builder/test/run --disable-dependency-tracking --disable-rpath --disable-silent-rules --disable-static --enable-debug --enable-shell --with-mysql --with-log4cplus --with-openssl --with-pgsql --with-gnu-ld && make && make install
4. Post installation observe that pid file is created in /home/builder/test/run/kea subdir
The reason I include autoreconf is because configure.ac is patched for systemd support before compilation.
**Expected behavior**
This is problematic when creating an rpm. I would expect it to be possible to set a specific pid file dir, lock file dir and log file dir pre compilation or documentation describing how to do properly. Or for the Kea build system to respect what autoreconf determines.
**Environment:**
- Kea version: 1.5.0
- OS: CentOS Linux release 7.5.1804 (Core)
- ./configure --prefix=/home/builder/test --localstatedir=/home/builder/test/run --disable-dependency-tracking --disable-rpath --disable-silent-rules --disable-static --enable-debug --enable-shell --with-mysql --with-log4cplus --with-openssl --with-pgsql --with-gnu-ld
**Describe the solution you'd like**
Some behaviour concerning pid file changed from version 1.4.0-P1. I have looked at commits and I can not pin point the specific commit which changed the behaviour. I would like at least be able to determine exact pid file placement before compilation, that is without the extra kea subdir.Kea1.6-beta2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/283perfdhcp: indicated requests rate is not kept during testing2019-01-18T16:02:09ZMichal Nowikowskiperfdhcp: indicated requests rate is not kept during testingDue to accumulating time slips in sending procedure the actual requests rate is lower than indicated.
It can be even ~20% lower for higher rates. Examples: 2700 instead of 3000.Due to accumulating time slips in sending procedure the actual requests rate is lower than indicated.
It can be even ~20% lower for higher rates. Examples: 2700 instead of 3000.Kea1.6Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/248ISC DHCP spawning classes2023-07-17T13:58:24ZFrancis DupontISC DHCP spawning classesISC DHCP has spawning classes:
>>>
Many cable modem head-end systems can be configured to add a Relay
Agent Information option to DHCP packets when relaying them to the DHCP
server. These systems typically ad...ISC DHCP has spawning classes:
>>>
Many cable modem head-end systems can be configured to add a Relay
Agent Information option to DHCP packets when relaying them to the DHCP
server. These systems typically add a circuit ID or remote ID option
that uniquely identifies the customer site. To take advantage of this,
you can write a class declaration as follows:
class "customer" {
spawn with option agent.circuit-id;
lease limit 4;
}
Now whenever a request comes in from a customer site, the circuit ID
option will be checked against the class's hash table. If a subclass
is found that matches the circuit ID, the client will be classified in
that subclass and treated accordingly. If no subclass is found match-
ing the circuit ID, a new one will be created and logged in the
dhcpd.leases file, and the client will be classified in this new class.
Once the client has been classified, it will be treated according to
the rules of the class, including, in this case, being subject to the
per-site limit of four leases.
The use of the subclass spawning mechanism is not restricted to relay
agent options - this particular example is given only because it is a
fairly straightforward one.
>>>
The important statement is the manual is:
>>>
The reason that spawning classes were created was to make it
possible to create lease-limited classes on the fly.
>>>
So they are very bound to the lease limitation feature. As Kea does not support it in fact the whole concept of spawning classes is useless for Kea...ISC DHCP MigrationFrancis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/225ISC DHCP server config option ddns-ttl2023-07-17T13:58:22ZFrancis DupontISC DHCP server config option ddns-ttlNo description in the manual. According to the code this option provides a way to set the DNS RR TTL in updates (vs using the lease timers). Can be useful?No description in the manual. According to the code this option provides a way to set the DNS RR TTL in updates (vs using the lease timers). Can be useful?kea2.3.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/219allow an option value to be set from an expression2019-10-25T09:31:24ZFrancis Dupontallow an option value to be set from an expressionISC DHCP has two ways to set an option value: the static one and the dynamic one where an expression is evaluated to give the value to use. Kea has the basic mechanism for expression evaluation so this feature should be implementable wit...ISC DHCP has two ways to set an option value: the static one and the dynamic one where an expression is evaluated to give the value to use. Kea has the basic mechanism for expression evaluation so this feature should be implementable without a large work.kea1.7.1Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/213Address cppcheck reports2019-11-07T16:54:03ZFrancis DupontAddress cppcheck reportsOn my macOS (cppcheck 1.85) I got ~1680 check_fails:
- 360 syntax errors on TEST/TEST_F
- 205 no explicit constructors
- 881 missing overrides
- 47 various styles (e.g. use STL algorithm, no copy constructor, no operator eq, variable...On my macOS (cppcheck 1.85) I got ~1680 check_fails:
- 360 syntax errors on TEST/TEST_F
- 205 no explicit constructors
- 881 missing overrides
- 47 various styles (e.g. use STL algorithm, no copy constructor, no operator eq, variable scope)
- 69 information (e.g. unmatched suppression, configuration not checked, too many configs)
- 38 passed by value performance hints
- 14 various performance hints (use initialization list, postfix operator, STL string find)
- 26 duplicated inherited member warnings
- 20 virtual call in constructor warnings
- 15 null pointer warnings
- 11 uninitialized member variable warnings
- 1 identical condition after early exit warning
- 1 identical inner condition warninghttps://gitlab.isc.org/isc-projects/kea/-/issues/205improve Kea guide2018-11-07T16:08:53ZMichal Nowikowskiimprove Kea guide- update list of distros which are used for Kea testing- update list of distros which are used for Kea testingKea1.5-beta1https://gitlab.isc.org/isc-projects/kea/-/issues/203sysrepo/netconf documentation improvements2018-12-12T23:14:46ZWlodzimierz Wencelsysrepo/netconf documentation improvementsSome of yang models have to be installed by hand and some of them are installed automatically as dependencies of those manually installed. So it would be nice that users guide would list every model that have to be installed by hand. I t...Some of yang models have to be installed by hand and some of them are installed automatically as dependencies of those manually installed. So it would be nice that users guide would list every model that have to be installed by hand. I think those models are: ietf-dhcpv6-server.yang
kea-dhcp4-server.yang
kea-dhcp6-server.yang
kea-dhcp-ddns.yang
kea-ctrl-agent.yang
ietf-inet-types.yang
ietf-yang-types.yang
for testing:
keatest-module.yang
Also docs is missing simple example how to start kea using sysrepocfg, it says ```Such changes can be done using sysrepocfg tool or remotely using any NETCONF client. For details, please see Sysrepo documentation``` and I really don't like the fact we are sending user to different documentation instead of having couple lines like:
```
sudo sysrepocfg -l 4 -d startup -f xml -i startup-4.xml kea-dhcp4-server
sudo sysrepocfg -l 4 -d running -f xml -i twopools-4.xml kea-dhcp4-server
```
with couple sentences explaining what "running" and "startup" datastores really are.Kea1.5-finalhttps://gitlab.isc.org/isc-projects/kea/-/issues/178Use detected python in shell unitests2018-11-28T14:45:12ZFrancis DupontUse detected python in shell unitestsI propose to replace python by @PYTHON@ in src/lib/shell/tests/Makefile.am so on (more and more common) systems where the default python is a python3 without a link to python (link which is explicitly **not** recommended to manually add)...I propose to replace python by @PYTHON@ in src/lib/shell/tests/Makefile.am so on (more and more common) systems where the default python is a python3 without a link to python (link which is explicitly **not** recommended to manually add) the shell unit tests can pass.
A good candidate for a final if we do not want it as soon as possible.Kea1.5-beta2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/175HA standby server clock skew2019-07-25T15:33:25ZGhost UserHA standby server clock skewHA has two devices and uses the same NTP server. The two servers have the same time. The standby server reports the following error.
`2018-10-19 09:41:31.520 ERROR [kea-dhcp4.ha-hooks/9478] HA_TERMINATED HA service terminated because of...HA has two devices and uses the same NTP server. The two servers have the same time. The standby server reports the following error.
`2018-10-19 09:41:31.520 ERROR [kea-dhcp4.ha-hooks/9478] HA_TERMINATED HA service terminated because of the unacceptable clock skew; fix the problem and restart!`Kea1.6-finalThomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/145feature request: ability to get lease count per pool2023-07-17T13:58:21ZGhost Userfeature request: ability to get lease count per pooltoday, when using the api command - "statistic-get-all"
we are getting a lease count at the subnet level,
i'm asking to get a count at the pool level.
thank you
#huge-sorrytoday, when using the api command - "statistic-get-all"
we are getting a lease count at the subnet level,
i'm asking to get a count at the pool level.
thank you
#huge-sorrykea2.3.8Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/130Provide sample ('complete') json configuration files with all the keys presen...2018-10-24T13:12:45ZCathy AlmondProvide sample ('complete') json configuration files with all the keys present, demonstrating their usageA Support customer asked (in ticket https://support.isc.org/Ticket/Display.html?id=13388):
```
I would like to have a complete json configuration file with all the "keys" present. Is this something you can help me with?
i have searched...A Support customer asked (in ticket https://support.isc.org/Ticket/Display.html?id=13388):
```
I would like to have a complete json configuration file with all the "keys" present. Is this something you can help me with?
i have searched but not found a complete configuration for kea 1.3 & 1.4
```
The engineering response was to craft a v4 configuration containing all keys or almost all keys. It comes with the following warning:
`Note that this configuration may not be valid, even though it is valid JSON, because usually we don't specify all keys. It is meant to be an example of what parameters can be specified at what level.`
This feature request is to formalise the need for such a document, and to extend it to cover other areas of Kea Configuration, starting with v6, and potentially extending to the control agent.
Meanwhile, here is what was generated for v4:
```
{
"Dhcp4": {
"next-server": "192.0.2.123",
"boot-file-name": "/dev/null",
"client-classes": [
{
"boot-file-name": "",
"name": "phones_server1",
"next-server": "0.0.0.0",
"option-data": [],
"option-def": [],
"server-hostname": "",
"test": "member('HA_server1')"
},
{
"boot-file-name": "",
"name": "phones_server2",
"next-server": "0.0.0.0",
"option-data": [],
"option-def": [],
"server-hostname": "",
"test": "member('HA_server2')"
},
{
"boot-file-name": "",
"name": "laptops_server1",
"next-server": "0.0.0.0",
"option-data": [],
"option-def": [],
"server-hostname": "",
"test": "member('HA_server1')"
},
{
"boot-file-name": "",
"name": "laptops_server2",
"next-server": "0.0.0.0",
"option-data": [],
"option-def": [],
"server-hostname": "",
"test": "member('HA_server2')"
}
],
"control-socket": {
"socket-name": "/tmp/kea-dhcp4-ctrl.sock",
"socket-type": "unix"
},
"decline-probation-period": 86400,
"dhcp-ddns": {
"always-include-fqdn": false,
"enable-updates": false,
"generated-prefix": "myhost",
"hostname-char-replacement": "",
"hostname-char-set": "",
"max-queue-size": 1024,
"ncr-format": "JSON",
"ncr-protocol": "UDP",
"override-client-update": false,
"override-no-update": false,
"qualifying-suffix": "",
"replace-client-name": "never",
"sender-ip": "0.0.0.0",
"sender-port": 0,
"server-ip": "127.0.0.1",
"server-port": 53001
},
"dhcp4o6-port": 0,
"echo-client-id": true,
"expired-leases-processing": {
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"reclaim-timer-wait-time": 10,
"unwarned-reclaim-cycles": 5
},
"hooks-libraries": [
{
"library": "/home/marcin/devel/kea-build/lib/hooks/libdhcp_lease_cmds.so",
"parameters": {}
},
{
"library": "/home/marcin/devel/kea-build/lib/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [
{
"heartbeat-delay": 10000,
"max-ack-delay": 5000,
"max-response-delay": 10000,
"max-unacked-clients": 0,
"mode": "load-balancing",
"peers": [
{
"auto-failover": true,
"name": "server1",
"role": "primary",
"url": "http://192.168.56.33:8080/"
},
{
"auto-failover": true,
"name": "server2",
"role": "secondary",
"url": "http://192.168.56.66:8080/"
}
],
"send-lease-updates": true,
"state-machine": {
"states": [
{
"pause": "always",
"state": "waiting"
},
{
"pause": "once",
"state": "partner-down"
}
]
},
"sync-leases": true,
"sync-timeout": 60000,
"this-server-name": "server1"
}
]
}
}
],
"host-reservation-identifiers": [
"hw-address",
"duid",
"circuit-id",
"client-id"
],
"interfaces-config": {
"dhcp-socket-type": "udp",
"interfaces": [
"enp0s8"
],
"re-detect": true
},
"lease-database": {
"lfc-interval": 3600,
"name": "/home/marcin/devel/kea-build/kea-dhcp4.csv",
"persist": true,
"type": "memfile"
},
"option-data": [
{
"always-send": false,
"code": 6,
"csv-format": true,
"data": "192.0.3.1, 192.0.3.2",
"name": "domain-name-servers",
"space": "dhcp4"
}
],
"option-def": [],
"rebind-timer": 40,
"renew-timer": 30,
"sanity-checks": {
"lease-checks": "warn"
},
"shared-networks": [
{
"match-client-id": true,
"name": "my-secret-network",
"option-data": [],
"relay": {
"ip-addresses": []
},
"reservation-mode": "all",
"require-client-classes": [ "Client_foo" ],
"subnet4": [
{
"4o6-interface": "",
"4o6-interface-id": "",
"4o6-subnet": "",
"boot-file-name": "",
"id": 1,
"match-client-id": true,
"next-server": "0.0.0.0",
"option-data": [
{
"always-send": false,
"code": 3,
"csv-format": true,
"data": "192.0.3.1",
"name": "routers",
"space": "dhcp4"
}
],
"pools": [
{
"client-class": "phones_server1",
"option-data": [],
"pool": "192.1.0.1/16"
},
{
"client-class": "laptops_server1",
"option-data": [],
"pool": "192.2.0.1/16"
},
{
"client-class": "phones_server2",
"option-data": [],
"pool": "192.3.0.1/16"
},
{
"client-class": "laptops_server2",
"option-data": [],
"pool": "192.4.0.1/16"
}
],
"rebind-timer": 40,
"relay": {
"ip-addresses": [
"192.168.56.1"
]
},
"renew-timer": 30,
"reservation-mode": "all",
"reservations": [],
"require-client-classes": [ "Client_foo" ],
"server-hostname": "",
"subnet": "192.0.0.0/8",
"valid-lifetime": 6000
}
]
}
],
"subnet4": [],
"valid-lifetime": 6000
},
"Logging": {
"loggers": [
{
"debuglevel": 99,
"name": "kea-dhcp4",
"output_options": [
{
"flush": true,
"maxsize": 10240000,
"maxver": 1,
"output": "stdout"
}
],
"severity": "INFO"
},
{
"debuglevel": 99,
"name": "kea-dhcp4.ha_hooks",
"output_options": [
{
"flush": true,
"maxsize": 10240000,
"maxver": 1,
"output": "stdout"
}
],
"severity": "INFO"
},
{
"debuglevel": 99,
"name": "kea-dhcp4.commands",
"output_options": [
{
"flush": true,
"maxsize": 10240000,
"maxver": 1,
"output": "stdout"
}
],
"severity": "INFO"
},
{
"debuglevel": 99,
"name": "kea-dhcp4.http",
"output_options": [
{
"flush": true,
"maxsize": 10240000,
"maxver": 1,
"output": "stdout"
}
],
"severity": "INFO"
}
]
}
}
```Kea1.5-beta2Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/79HA: Consider adding HA status command to keactrl [ISC-support #14719]2023-05-25T17:19:58ZGhost UserHA: Consider adding HA status command to keactrl [ISC-support #14719]We've got a feature request from a Kea 1.4.0 beta tester. The user is asking whether we could provide a tool to be used locally for checking the server's HA state. We may consider adding this to keactrl. The implementation could simply s...We've got a feature request from a Kea 1.4.0 beta tester. The user is asking whether we could provide a tool to be used locally for checking the server's HA state. We may consider adding this to keactrl. The implementation could simply send the ha-heartbeat command to the local server via unix domain socket and then parse the JSON response.
Related issue #318.kea1.7.6Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/3313Bump up version in configure.ac to 2.5.8-git2024-03-26T19:09:46ZMarcin GodzinaBump up version in configure.ac to 2.5.8-gitBump up version in configure.ac.Bump up version in configure.ac.kea2.5.8Marcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/kea/-/issues/3309Sanity checks for Kea 2.5.7 rc12024-03-26T06:25:10ZMarcin GodzinaSanity checks for Kea 2.5.7 rc1We are now at step SANITY CHECKS of Kea 2.5.7 rc1.
Please verify the tarballs and packages according to [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-co...We are now at step SANITY CHECKS of Kea 2.5.7 rc1.
Please verify the tarballs and packages according to [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-content-4-sanity-checks) and according to your imagination.
Before starting, please state what you are checking in a thread/discussion (not as comment).
When you finish a check, state in the same thread/discussion what the result is.
This way we know what is covered upfront and we can avoid repeating ourselves.
#### Tarballs on repo.isc.org
* `/data/shared/sweng/kea/releases/2.5.7-rc1`
* `/data/shared/sweng/kea/releases/premium-2.5.7-rc1`
* `/data/shared/sweng/kea/releases/subscription-2.5.7-rc1`
* `/data/shared/sweng/kea/releases/enterprise-2.5.7-rc1`
```
SHA256 (kea-2.5.7.tar.gz) = 7a3a05ca11b5fe8c4e72a31169b6bed94368c4a7af6d388c86321da96568a1d4
SHA256 (kea-enterprise-2.5.7.tar.gz) = f61c1636df974c4531060d93218baf569b77a50f944882558593be8737984911
SHA256 (kea-premium-2.5.7.tar.gz) = 5c82b56a3e338f5f664a04fd1c271e0a8ff2dfd610dee0416dbfca8ee4f830a4
SHA256 (kea-subscription-2.5.7.tar.gz) = 42aa2106fb0595d23976807988a2f4b546f5bad718efdffce2af9b6bdd867aba
```
#### Packages on packages.aws.isc.org
* [APK: 2.5.7-r20240322162202](https://packages.aws.isc.org/#browse/search/raw=format%3Draw%20AND%20name.raw%3D*r20240322162202.apk)
* [deb: 2.5.7-isc20240322162202](https://packages.aws.isc.org/#browse/search/apt=format%3Dapt%20AND%20version%3D2.5.7-isc20240322162202)
* [RPM: 2.5.7-isc20240322162202.\[os\]](https://packages.aws.isc.org/#browse/search/yum=format%3Dyum%20AND%20version%3D2.5.7-isc20240322162202*)
You can find the name for all the packages attached as build artifacts in the pkg job: https://jenkins.aws.isc.org/job/kea-dev/job/pkg/1460/
Instructions for installing packages are at point 9 of [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-content-4-sanity-checks).kea2.5.72024-03-25