SECURITY UPDATE: net/kea. Tests/feedback needed.

[Stuart Henderson]

I noticed there was a security update for net/kea and then noticed
that the port is rather outdated. I don't use it myself (and config is a
bit fiddly) so I haven't tested beyond building.

Is anyone still using it? If so, please test and report back.

If not, I propose removing the port until a maintainer or at least someone
who can test updates is found.

Index: Makefile
===
RCS file: /cvs/ports/net/kea/Makefile,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile
--- Makefile12 Jul 2019 20:48:29 -  1.16
+++ Makefile29 Aug 2019 11:37:36 -
@@ -2,35 +2,21 @@
 
 COMMENT=   high-performance and extensible DHCP server engine from ISC
 
-VERSION=   1.2.0
+VERSION=   1.6.0
 
 DISTNAME=  kea-${VERSION}
 PKGNAME=   ${DISTNAME:S/-P/pl/}
-REVISION=  4
 
-SHARED_LIBS +=  kea-asiodns   0.0 # 0.0
-SHARED_LIBS +=  kea-asiolink  2.0 # 4.0
-SHARED_LIBS +=  kea-cc1.0 # 2.0
-SHARED_LIBS +=  kea-cfgclient 1.0 # 3.0
-SHARED_LIBS +=  kea-cryptolink1.0 # 2.0
-SHARED_LIBS +=  kea-dhcp++2.0 # 5.0
-SHARED_LIBS +=  kea-dhcp_ddns 0.2 # 1.2
-SHARED_LIBS +=  kea-dhcpsrv   2.0 # 7.0
-SHARED_LIBS +=  kea-dns++ 1.0 # 1.1
-SHARED_LIBS +=  kea-eval  2.0 # 5.0
-SHARED_LIBS +=  kea-exceptions0.0 # 0.0
-SHARED_LIBS +=  kea-hooks 2.0 # 3.0
-SHARED_LIBS +=  kea-http  0.0 # 0.0
-SHARED_LIBS +=  kea-log   2.0 # 3.0
-SHARED_LIBS +=  kea-process   0.0 # 0.0
-SHARED_LIBS +=  kea-stats 0.0 # 1.0
-SHARED_LIBS +=  kea-threads   1.0 # 1.0
-SHARED_LIBS +=  kea-util-io   0.0 # 0.0
-SHARED_LIBS +=  kea-util  1.1 # 2.1
+.for i in kea-exceptions kea-util kea-util-io kea-threads kea-log \
+  kea-cryptolink kea-dns++ kea-asiolink kea-cc kea-database kea-hooks \
+  kea-dhcp++ kea-cfgclient kea-stats kea-asiodns kea-dhcp_ddns \
+  kea-eval kea-process kea-dhcpsrv kea-http
+SHARED_LIBS +=  $i 3.0
+.endfor
 
 CATEGORIES=net
 
-HOMEPAGE=  http://kea.isc.org/
+HOMEPAGE=  https://kea.isc.org/
 
 # MPL 2.0
 PERMIT_PACKAGE=Yes
@@ -58,18 +44,14 @@ FLAVOR?=
 
 .if ${FLAVOR:Mmysql}
 WANTLIB += mysqlclient ssl z
-
 LIB_DEPENDS+=  databases/mariadb
-
 CONFIGURE_ARGS+= --with-dhcp-mysql=${LOCALBASE}/bin/mysql_config
 .endif
 
 .if ${FLAVOR:Mpostgresql}
 WANTLIB += pq ssl
-
 BUILD_DEPENDS+=databases/postgresql,-server
 LIB_DEPENDS+=  databases/postgresql
-
 CONFIGURE_ARGS+= --with-dhcp-pgsql=${LOCALBASE}/bin/pg_config
 .endif
 
Index: distinfo
===
RCS file: /cvs/ports/net/kea/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo27 Aug 2017 11:14:51 -  1.4
+++ distinfo29 Aug 2019 11:37:36 -
@@ -1,2 +1,2 @@
-SHA256 (kea-1.2.0.tar.gz) = ItFZRbE2ALVsNyE3l8ofPumFHmEZEgrq4IAzxMxS0Sk=
-SIZE (kea-1.2.0.tar.gz) = 5720941
+SHA256 (kea-1.6.0.tar.gz) = RO1IxynkYY//zwCGUptGn3IymQmDGHsvcfzonxrG4nA=
+SIZE (kea-1.6.0.tar.gz) = 7154301
Index: patches/patch-src_bin_keactrl_kea-ca_conf_pre
===
RCS file: patches/patch-src_bin_keactrl_kea-ca_conf_pre
diff -N patches/patch-src_bin_keactrl_kea-ca_conf_pre
--- patches/patch-src_bin_keactrl_kea-ca_conf_pre   27 Aug 2017 11:14:51 
-  1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,19 +0,0 @@
-$OpenBSD: patch-src_bin_keactrl_kea-ca_conf_pre,v 1.1 2017/08/27 11:14:51 
sthen Exp $
-
-Index: src/bin/keactrl/kea-ca.conf.pre
 src/bin/keactrl/kea-ca.conf.pre.orig
-+++ src/bin/keactrl/kea-ca.conf.pre
-@@ -11,11 +11,11 @@
- "control-sockets": {
- "dhcp4-server": {
- "socket-type": "unix",
--"socket-name": "/tmp/kea-dhcp4-ctrl.sock"
-+"socket-name": "@localstatedir@/run/kea/kea-dhcp4-ctrl.sock"
- },
- "dhcp6-server": {
- "socket-type": "unix",
--"socket-name": "/tmp/kea-dhcp6-ctrl.sock"
-+"socket-name": "@localstatedir@/run/kea/kea-dhcp6-ctrl.sock"
- }
- },
- 
Index: patches/patch-src_bin_keactrl_kea-ctrl-agent_conf_pre
===
RCS file: patches/patch-src_bin_keactrl_kea-ctrl-agent_conf_pre
diff -N patches/patch-src_bin_keactrl_kea-ctrl-agent_conf_pre
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_bin_keactrl_kea-ctrl-agent_conf_pre   29 Aug 2019 
11:37:36 -
@@ -0,0 +1,33 @@
+$OpenBSD$
+
+Index: src/bin/keactrl/kea-ctrl-agent.conf.pre
+--- src/bin/keactrl/kea-ctrl-agent.conf.pre.ori

Re: net/kea: 1.2.0

[Patrik Lundin]

On Sun, Aug 27, 2017 at 11:19:44AM +0100, Stuart Henderson wrote:
> On 2017/08/27 12:07, Patrik Lundin wrote:
> > On Sat, Aug 12, 2017 at 11:39:14PM +0200, Patrik Lundin wrote:
> > > 
> > > Since there have been no further feedback, is there a chance the latest
> > > diff can get commited?
> > > 
> > 
> > Ping.
> 
> The COMPILER infrastructure changed in the meantime, I'm leaving it building
> now and should be able to pick it up later today.
> 

I saw the commit, thank you Stuart :).

-- 
Patrik Lundin

Re: net/kea: 1.2.0

[Stuart Henderson]

On 2017/08/27 12:07, Patrik Lundin wrote:
> On Sat, Aug 12, 2017 at 11:39:14PM +0200, Patrik Lundin wrote:
> > 
> > Since there have been no further feedback, is there a chance the latest
> > diff can get commited?
> > 
> 
> Ping.

The COMPILER infrastructure changed in the meantime, I'm leaving it building
now and should be able to pick it up later today.

Re: net/kea: 1.2.0

[Patrik Lundin]

On Sat, Aug 12, 2017 at 11:39:14PM +0200, Patrik Lundin wrote:
> 
> Since there have been no further feedback, is there a chance the latest
> diff can get commited?
> 

Ping.

-- 
Patrik Lundin

Re: net/kea: 1.2.0

[Patrik Lundin]

On Thu, Aug 03, 2017 at 10:24:00PM +0200, Patrik Lundin wrote:
> 
> Thanks for spotting that. New diff against fresh ports tree below (and
> now portcheck is happy as well).
> 

Since there have been no further feedback, is there a chance the latest
diff can get commited?

-- 
Patrik Lundin

Re: net/kea: 1.2.0

[Patrik Lundin]

Hello Stuart, thanks for the review.

On Thu, Aug 03, 2017 at 06:43:11PM +0100, Stuart Henderson wrote:
> 
> clang is already used as the compiler on i386/amd64/aarch64. Just using
> "COMPILER=clang" means this won't build on some arch which do have c++11
> support from ports gcc.
> 
> For most things "COMPILER=gcc" is generally now the best option for c++11
> ports, this means "build with clang if it's in base, otherwise build with
> ports gcc".
> 

Thank you for the information. I will use "gcc" instead.

> > * Use /var/run/kea instead of /tmp for the UNIX domain control sockets
> >   introduced in 1.2.0.
> 
> Please subst with ${LOCALSTATEDIR} instead of hardcoding /var.
> 

Sorry about that. While using ${LOCALSTATEDIR} directly in the .pre
files does not work, I have used the @localstatedir@ markers instead
(which is used in other places in the files already).

> 
> It's no longer LIBCXX but COMPILER_LIBCXX, which made me spot that your cvs
> diff is against Makefile r1.7 (post-6.1 but pre-current) .. so your ports tree
> (which includes portcheck) needs an update.
> 

Thanks for spotting that. New diff against fresh ports tree below (and
now portcheck is happy as well).

I also noticed something I had missed in the configure output previously:
===
./configure[16315]: test: >: unexpected operator/operand
===

I opened a PR for that:
https://github.com/isc-projects/kea/pull/53

I dont feel that warrants a port patch though as I don't think the
outcome matters on OpenBSD.

-- 
Patrik Lundin

Index: Makefile
===
RCS file: /cvs/ports/net/kea/Makefile,v
retrieving revision 1.9
diff -u -p -u -r1.9 Makefile
--- Makefile26 Jul 2017 22:45:27 -  1.9
+++ Makefile3 Aug 2017 20:17:26 -
@@ -2,29 +2,30 @@
 
 COMMENT=   high-performance and extensible DHCP server engine from ISC
 
-VERSION=   1.1.0
+VERSION=   1.2.0
 
 DISTNAME=  kea-${VERSION}
 PKGNAME=   ${DISTNAME:S/-P/pl/}
-REVISION=  0
 
 SHARED_LIBS +=  kea-asiodns   0.0 # 0.0
-SHARED_LIBS +=  kea-asiolink  1.0 # 3.0
-SHARED_LIBS +=  kea-cc0.0 # 1.0
-SHARED_LIBS +=  kea-cfgclient 0.1 # 2.1
-SHARED_LIBS +=  kea-cryptolink0.0 # 1.0
-SHARED_LIBS +=  kea-dhcp++1.0 # 4.1
-SHARED_LIBS +=  kea-dhcp_ddns 0.1 # 1.1
-SHARED_LIBS +=  kea-dhcpsrv   1.0 # 6.0
-SHARED_LIBS +=  kea-dns++ 0.0 # 2.0
-SHARED_LIBS +=  kea-eval  1.0 # 4.0
+SHARED_LIBS +=  kea-asiolink  2.0 # 4.0
+SHARED_LIBS +=  kea-cc1.0 # 2.0
+SHARED_LIBS +=  kea-cfgclient 1.0 # 3.0
+SHARED_LIBS +=  kea-cryptolink1.0 # 2.0
+SHARED_LIBS +=  kea-dhcp++2.0 # 5.0
+SHARED_LIBS +=  kea-dhcp_ddns 0.2 # 1.2
+SHARED_LIBS +=  kea-dhcpsrv   2.0 # 7.0
+SHARED_LIBS +=  kea-dns++ 1.0 # 1.1
+SHARED_LIBS +=  kea-eval  2.0 # 5.0
 SHARED_LIBS +=  kea-exceptions0.0 # 0.0
-SHARED_LIBS +=  kea-hooks 1.0 # 2.0
-SHARED_LIBS +=  kea-log   1.0 # 2.0
+SHARED_LIBS +=  kea-hooks 2.0 # 3.0
+SHARED_LIBS +=  kea-http  0.0 # 0.0
+SHARED_LIBS +=  kea-log   2.0 # 3.0
+SHARED_LIBS +=  kea-process   0.0 # 0.0
 SHARED_LIBS +=  kea-stats 0.0 # 1.0
 SHARED_LIBS +=  kea-threads   1.0 # 1.0
 SHARED_LIBS +=  kea-util-io   0.0 # 0.0
-SHARED_LIBS +=  kea-util  1.0 # 2.0
+SHARED_LIBS +=  kea-util  1.1 # 2.1
 
 CATEGORIES=net
 
@@ -50,6 +51,9 @@ CONFIGURE_ARGS+= --with-openssl=/usr \
  --with-boost-lib-dir=${LOCALBASE}/lib
 
 LIBTOOL_FLAGS= --tag=disable-static
+
+# configure: error: std::unique_ptr (a C++11 feature) is not supported
+COMPILER= gcc
 
 FLAVORS=   mysql postgresql
 FLAVOR?=
Index: distinfo
===
RCS file: /cvs/ports/net/kea/distinfo,v
retrieving revision 1.3
diff -u -p -u -r1.3 distinfo
--- distinfo13 Nov 2016 14:58:18 -  1.3
+++ distinfo3 Aug 2017 20:17:26 -
@@ -1,2 +1,2 @@
-SHA256 (kea-1.1.0.tar.gz) = w9l67k+qGWU//m0355fi+/YyEkzQuYu1Avm5e1o4PC0=
-SIZE (kea-1.1.0.tar.gz) = 4934875
+SHA256 (kea-1.2.0.tar.gz) = ItFZRbE2ALVsNyE3l8ofPumFHmEZEgrq4IAzxMxS0Sk=
+SIZE (kea-1.2.0.tar.gz) = 5720941
Index: patches/patch-src_bin_dhcp4_tests_dhcp4_process_tests_sh_in
===
RCS file: patches/patch-src_bin_dhcp4_tests_dhcp4_process_tests_sh_in
diff -N patches/patch-src_bin_dhcp4_tests_dhcp4_process_tests_sh_in
--- patches/patch-src_bin_dhcp4_tests_dhcp4_process_tests_sh_in 28 Feb 2017 
08:57:12 -  1.1
+++ /dev/null   1 Jan 1970 00:00:00 

Re: net/kea: 1.2.0

[Stuart Henderson]

On 2017/08/03 19:12, Patrik Lundin wrote:
> * Start using clang as the compiler. Kea 1.2.0 requires C++11 support.
>   With the clang work taking place in base I noticed espie@ had already
>   added a patch for a clang build breaking problem. This has been reported and
>   fixed upstream for later editions:
>   
> https://github.com/isc-projects/kea/commit/75691636ab9421297cfc353b0954aa2e8c82

clang is already used as the compiler on i386/amd64/aarch64. Just using
"COMPILER=clang" means this won't build on some arch which do have c++11
support from ports gcc.

For most things "COMPILER=gcc" is generally now the best option for c++11
ports, this means "build with clang if it's in base, otherwise build with
ports gcc".

> * Use /var/run/kea instead of /tmp for the UNIX domain control sockets
>   introduced in 1.2.0.

Please subst with ${LOCALSTATEDIR} instead of hardcoding /var.

> I did notice that portcheck is currently complaining:
> ===
> # /usr/ports/infrastructure/bin/portcheck
> in default FLAVOR: stdc++ in WANTLIB when gcc4 is in MODULES; run 
> port-lib-depends-check and if stdc++ is still there, check actual build 
> thoroughly, it's broken
> in FLAVOR "mysql": stdc++ in WANTLIB when gcc4 is in MODULES; run 
> port-lib-depends-check and if stdc++ is still there, check actual build 
> thoroughly, it's broken
> in FLAVOR "postgresql": stdc++ in WANTLIB when gcc4 is in MODULES; run 
> port-lib-depends-check and if stdc++ is still there, check actual build 
> thoroughly, it's broken
> net/kea
> ===
> 
> I believe this is a result of ${LIBCXX} being part of WANTLIB. This is
> not something that has been added by me, so I am unsure what the correct
> solution is. Here is the output of the requested port-lib-depends-check:
> ===
> # make port-lib-depends-check
> 
> kea-1.2.0(net/kea):
> Extra:  stdc++.57
> ===
> 
> Any input on this?

It's no longer LIBCXX but COMPILER_LIBCXX, which made me spot that your cvs
diff is against Makefile r1.7 (post-6.1 but pre-current) .. so your ports tree
(which includes portcheck) needs an update.

> 

net/kea: 1.2.0

[Patrik Lundin]

Hello,

Below is a work in progress of an update of net/kea to 1.2.0.

The complete release notes for 1.2.0 can be seen here:
https://deepthought.isc.org/article/AA-01494

>From the perspective of the port I have made the following updates:
* Start using clang as the compiler. Kea 1.2.0 requires C++11 support.
  With the clang work taking place in base I noticed espie@ had already
  added a patch for a clang build breaking problem. This has been reported and
  fixed upstream for later editions:
  
https://github.com/isc-projects/kea/commit/75691636ab9421297cfc353b0954aa2e8c82

* Make the example configuration log to syslog. This means there are no
  custom log files created that you will need to create your own log
  rotation for unless you really want to. The following files are no
  longer created because of this:

  /var/kea/kea.log
  /var/log/kea-ddns.log
  /var/log/kea-dhcp4.log
  /var/log/kea-dhcp6.log

* Set lfc-interval to 3600 seconds in the configuraion file. This
  enables cleanup of the memfile database files. It is a sane default
  and discussions to make this either a part of the standard config file
  or make it the unconfigured default is part of a ticket created
  upstream: http://kea.isc.org/ticket/5341

* Use /var/run/kea instead of /tmp for the UNIX domain control sockets
  introduced in 1.2.0.

I did notice that portcheck is currently complaining:
===
# /usr/ports/infrastructure/bin/portcheck
in default FLAVOR: stdc++ in WANTLIB when gcc4 is in MODULES; run 
port-lib-depends-check and if stdc++ is still there, check actual build 
thoroughly, it's broken
in FLAVOR "mysql": stdc++ in WANTLIB when gcc4 is in MODULES; run 
port-lib-depends-check and if stdc++ is still there, check actual build 
thoroughly, it's broken
in FLAVOR "postgresql": stdc++ in WANTLIB when gcc4 is in MODULES; run 
port-lib-depends-check and if stdc++ is still there, check actual build 
thoroughly, it's broken
net/kea
===

I believe this is a result of ${LIBCXX} being part of WANTLIB. This is
not something that has been added by me, so I am unsure what the correct
solution is. Here is the output of the requested port-lib-depends-check:
===
# make port-lib-depends-check

kea-1.2.0(net/kea):
Extra:  stdc++.57
===

Any input on this?

-- 
Patrik Lundin

Index: Makefile
===
RCS file: /cvs/ports/net/kea/Makefile,v
retrieving revision 1.7
diff -u -p -u -r1.7 Makefile
--- Makefile10 Apr 2017 11:46:32 -  1.7
+++ Makefile3 Aug 2017 16:42:05 -
@@ -2,28 +2,30 @@
 
 COMMENT=   high-performance and extensible DHCP server engine from ISC
 
-VERSION=   1.1.0
+VERSION=   1.2.0
 
 DISTNAME=  kea-${VERSION}
 PKGNAME=   ${DISTNAME:S/-P/pl/}
 
 SHARED_LIBS +=  kea-asiodns   0.0 # 0.0
-SHARED_LIBS +=  kea-asiolink  1.0 # 3.0
-SHARED_LIBS +=  kea-cc0.0 # 1.0
-SHARED_LIBS +=  kea-cfgclient 0.1 # 2.1
-SHARED_LIBS +=  kea-cryptolink0.0 # 1.0
-SHARED_LIBS +=  kea-dhcp++1.0 # 4.1
-SHARED_LIBS +=  kea-dhcp_ddns 0.1 # 1.1
-SHARED_LIBS +=  kea-dhcpsrv   1.0 # 6.0
-SHARED_LIBS +=  kea-dns++ 0.0 # 2.0
-SHARED_LIBS +=  kea-eval  1.0 # 4.0
+SHARED_LIBS +=  kea-asiolink  2.0 # 4.0
+SHARED_LIBS +=  kea-cc1.0 # 2.0
+SHARED_LIBS +=  kea-cfgclient 1.0 # 3.0
+SHARED_LIBS +=  kea-cryptolink1.0 # 2.0
+SHARED_LIBS +=  kea-dhcp++2.0 # 5.0
+SHARED_LIBS +=  kea-dhcp_ddns 0.2 # 1.2
+SHARED_LIBS +=  kea-dhcpsrv   2.0 # 7.0
+SHARED_LIBS +=  kea-dns++ 1.0 # 1.1
+SHARED_LIBS +=  kea-eval  2.0 # 5.0
 SHARED_LIBS +=  kea-exceptions0.0 # 0.0
-SHARED_LIBS +=  kea-hooks 1.0 # 2.0
-SHARED_LIBS +=  kea-log   1.0 # 2.0
+SHARED_LIBS +=  kea-hooks 2.0 # 3.0
+SHARED_LIBS +=  kea-http  0.0 # 0.0
+SHARED_LIBS +=  kea-log   2.0 # 3.0
+SHARED_LIBS +=  kea-process   0.0 # 0.0
 SHARED_LIBS +=  kea-stats 0.0 # 1.0
 SHARED_LIBS +=  kea-threads   1.0 # 1.0
 SHARED_LIBS +=  kea-util-io   0.0 # 0.0
-SHARED_LIBS +=  kea-util  1.0 # 2.0
+SHARED_LIBS +=  kea-util  1.1 # 2.1
 
 CATEGORIES=net
 
@@ -49,6 +51,9 @@ CONFIGURE_ARGS+= --with-openssl=/usr \
  --with-boost-lib-dir=${LOCALBASE}/lib
 
 LIBTOOL_FLAGS= --tag=disable-static
+
+# configure: error: std::unique_ptr (a C++11 feature) is not supported
+COMPILER= clang
 
 FLAVORS=   mysql postgresql
 FLAVOR?=
Index: distinfo
===
RCS file: /cvs/ports/net/kea/distinfo,v
retrieving revision 1.3
diff -u -p -u -r1.3 distinfo
--- distinfo13 Nov 2016 14:58:18 -  1.3
+++ distinfo3 

Re: net/kea: 1.1.0

[Jeremie Courreges-Anglas]

Patrik Lundin <pat...@sigterm.se> writes:

> Hello,
>
> See below for an update to net/kea from 1.0.0 to 1.1.0.

Committed, thanks.

[...]

> This also brings up another question of mine: where to place logs.
>
> Currently the default setup creates logs in the following places:
> /var/kea/kea.log
   ^^^
> /var/log/kea-ddns.log
vs ^^^, weird...
> /var/log/kea-dhcp4.log
> /var/log/kea-dhcp6.log
>
> Of course the port does not do anything to setup rotation of these logs. Any
> input how this should be handled?

I guess you could put a newsyslog.conf example in pkg/README.

[...]

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: net/kea: 1.1.0

[Patrik Lundin]

On Mon, Oct 10, 2016 at 12:28:58AM +0200, Patrik Lundin wrote:
> Hello,
> 
> See below for an update to net/kea from 1.0.0 to 1.1.0.
> 

Ping.

-- 
Patrik Lundin

net/kea: 1.1.0

[Patrik Lundin]

Hello,

See below for an update to net/kea from 1.0.0 to 1.1.0.

>From the release statement
(https://kb.isc.org/article/AA-01428/0/Kea-1.1.0-Release-Notes.html):
===

* Additional Database Backend - Kea 1.1.0 has added preliminary support for
  Cassandra as a database backend.  In this release of Kea it can only be used
  to store lease information, it is not able store host reservations.
  Cassandra support is currently considered experimental. Use with caution.

* Host Reservations - Kea 1.0 contained limited support for storing host
  reservations in the database backend.  Kea 1.1.0 has expanded that
  capability, allowing host reservations to be stored in a MySQL or
  PostgreSQL database. In particular, Kea 1.1.0:
  - Adds host reservation (DHCPv4 and DHCPv6) using the PostgreSQL backend.
  - Adds host reservation for DHCPv6 to the existing MySQL support.
  - Significantly extends the existing host reservation capabilities to
include reservations of specific DHCP options, reservations of siaddr,
sname, and file fields within DHCPv4 messages, and reservations of
multiple IPv6 addresses/prefixes.
  - Allows the MySQL or PostgreSQL host reservation database to be configured
read-only, in which case Kea will be able to retrieve reservations from it,
but not insert or update existing reservations. This feature is useful
when a database (or database view) exists for the particular deployment
and the administrator doesn't want to grant read-write access for security
reasons.

* Client Classification - In Kea 1.1 the client classification system has been
  expanded. A class definition contains a name and a test expression of
  arbitrary complexity; if the test expression evaluates to "true" the client
  is a member of that class.  A client may be a member of multiple classes and
  can acquire options from different classes.   If the configuration contains
  multiple definitions for data for an option in two or more of the global,
  class, subnet or host entries, the server will choose the definition from
  the most specific entry.

  There are a number of objects and operators available for use in the test
  expression.
  - Operators include: equal, not, and, or, substring, concat
  - Objects include:
   - literals: string, hexadecimal, IP address and integer
   - options: existence and content
   - relay options for DHCPv4 and DHCPv6: existence and content
   - subfields within vendor and vendor class options: existence,
 enterprise-id value and content
   - selected fields from DHCPv4 and DHCPv6 packets
  - Classes may be used to select subnets
  - Classes and class specific subnets may contain option data to serve to
clients within that class

* Hook Library Parameters - It is now possible to specify parameters for hook
  libraries in the Kea configuration file. In earlier versions of Kea, hook
  library authors had to use a external mechanism (such as file of a known
  name) to pass information across.

* DHCPv4-over-DHCPv6 - RFC7341 (https://tools.ietf.org/html/rfc7341) defines
  an architecture that allows dual-stack clients to communicate with DHCPv4
  server in IPv6-only networks. Kea 1.1 introduces support for this mode of
  operation. It requires running both DHCPv4 and DHCPv6 servers in special
  mode, where DHCPv6 component does not allocate anything, but decapsulates
  incoming DHCPv4 messages, sends the to the DHCPv4 server and then relay
  back the responses.
===

Note that I have not addded any build options for the cassandra version, since
there is no cassandra port available.

This also brings up another question of mine: where to place logs.

Currently the default setup creates logs in the following places:
/var/kea/kea.log
/var/log/kea-ddns.log
/var/log/kea-dhcp4.log
/var/log/kea-dhcp6.log

Of course the port does not do anything to setup rotation of these logs. Any
input how this should be handled? There are currently some problems with the
syslog code (formatting of the messages and problems with setting the syslog
facility) that is stopping me from making that the default configuration.

These questions apply for the version currently in-tree, so not a new
problem introduced by the update.

The syslog issues as well as the added patches for fixing the test suite are
being discussed upstream in this thread:
https://lists.isc.org/pipermail/kea-users/2016-September/000547.html
https://lists.isc.org/pipermail/kea-users/2016-October/000560.html

Other then that the library versions of the port have been bumped based on
shared_libs.log in WRKSRC.

-- 
Patrik Lundin

Index: Makefile
===
RCS file: /cvs/ports/net/kea/Makefile,v
retrieving revision 1.5
diff -u -p -u -r1.5 Makefile
--- Makefile14 Mar 2016 06:46:24 -  1.5
+++ Makefile9 Oct 2016 21:10:57 -
@@ -2,28 +2,28 @@
 
 COMMENT=   high-performance and extensible DHCP server engine from ISC
 
-VERSION

Re: net/kea: Ensure base awk is used

[Christian Weisgerber]

On 2016-06-27, Stuart Henderson  wrote:

> ...but there's also this in config.site, which seems incorrect:
>
> ac_cv_prog_AWK=${ac_cv_prog_AWK=awk}

If you mean that it should use the full path, then no, it's correct
as is.  Putting /usr/bin/awk there causes build errors, because
some of the autoconf magic that uses ac_cv_prog_AWK can't handle a
full path.

We have:

  config.site:
  ac_cv_prog_AWK=${ac_cv_prog_AWK=awk}

  config.no-gawk:
  ac_cv_prog_AWK=${ac_cv_prog_AWK=/usr/bin/awk}

Since ac_cv_prog_AWK is already set, the entry in config.no-gawk
is never used.  Instead we want to set ac_cv_path_AWK in config.no-gawk.

I suggest the patch below.  I've had this in the last two amd64
bulk builds.  Yes, here the full path is fine.

OK?

Index: config.no-gawk
===
RCS file: /cvs/ports/infrastructure/db/config.no-gawk,v
retrieving revision 1.1
diff -u -r1.1 config.no-gawk
--- config.no-gawk  12 Dec 2011 10:33:33 -  1.1
+++ config.no-gawk  6 Jul 2016 21:39:46 -
@@ -1,3 +1,3 @@
 # $OpenBSD: config.no-gawk,v 1.1 2011/12/12 10:33:33 jasper Exp $
 # included unless lang/gawk
-ac_cv_prog_AWK=${ac_cv_prog_AWK=/usr/bin/awk}
+ac_cv_path_AWK=${ac_cv_path_AWK=/usr/bin/awk}
-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: net/kea: Helpfully failing test in ./configure

[Patrik Lundin]

On Mon, Jun 27, 2016 at 07:44:07PM +0200, Jeremie Courreges-Anglas wrote:
> Patrik Lundin  writes:
> 
> >
> > This means that the failing "test" can actually be thought of as a
> > feature. It is of course brittle, and will modify the build parameters
> > if someone decides to teach the test builtin about "<" prior to bumping
> > base gcc past 4.5.
> 
> This is a very unlikely scenario.
> 
> > Basically I am just asking for pointers from other porters, anyone have
> > an idea how I should deal with this? Should I bother at all?
> 
> I guess you could just use /bin/test.
> 

I figured that such a gcc version bump is fairly unlikely but I would
rather ask than guess :). Thanks for the input, I'll see what upstream
thinks about the "expr" proposal. If they decide to merge it I will
return with a patch for the port.

-- 
Patrik Lundin

Re: net/kea: Helpfully failing test in ./configure

[Patrik Lundin]

On Mon, Jun 27, 2016 at 07:51:33PM +, Christian Weisgerber wrote:
> On 2016-06-27, Patrik Lundin  wrote:
> 
> > CXX_DUMP_VERSION=`$CXX -dumpversion | cut -f1-2 -d.`
> > if test "$CXX_DUMP_VERSION" \< "4.5"; then
> >WARNING_GCC_44_STRICT_ALIASING_CFLAG="-fno-strict-aliasing"
> > fi
> >
> > The error message is thrown because the builtin test does not support
> > the "<" operator (which /bin/test does).
> 
> That's not portable.  POSIX does not specify an operator < for test.
> 
> For a portable solution, use expr(1) instead.
> 

Thanks, that sounds like the most proper way forward. I have opened a PR
against upstream, lets see what they think:
https://github.com/isc-projects/kea/pull/25

I guess the side effect of fixing the check (adding
"-fno-strict-aliasing" to the build even if not strictly needed) is not
really detrimental to the build.

-- 
Patrik Lundin

Re: net/kea: Helpfully failing test in ./configure

[Christian Weisgerber]

On 2016-06-27, Patrik Lundin  wrote:

> CXX_DUMP_VERSION=`$CXX -dumpversion | cut -f1-2 -d.`
> if test "$CXX_DUMP_VERSION" \< "4.5"; then
>WARNING_GCC_44_STRICT_ALIASING_CFLAG="-fno-strict-aliasing"
> fi
>
> The error message is thrown because the builtin test does not support
> the "<" operator (which /bin/test does).

That's not portable.  POSIX does not specify an operator < for test.

For a portable solution, use expr(1) instead.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: net/kea: Ensure base awk is used

[Christian Weisgerber]

On 2016-06-27, Stuart Henderson  wrote:

>> That should already be set. Is it not picking up config.site for some reason?
>
> Oh, it is ac_cv_*prog*_AWK that is getting set, for some reason kea
> is also looking at ac_cv_*path*_AWK.
>
> Perhaps we should add the path variant to config.site then..

In fact, ac_cv_prog_AWK is set in both config.site and again in
config.no-gawk.  That doesn't make sense.

I suspect the intention was to set ac_cv_path_AWK in config.no-gawk.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: net/kea: Ensure base awk is used

[Stuart Henderson]

On 2016/06/27 21:10, David Coppa wrote:
> On Mon, Jun 27, 2016 at 6:26 PM, Stuart Henderson  
> wrote:
> 
> > Perhaps we should add the path variant to config.site then..
> 
> It looks like the right approach to me, ok dcoppa@.

These are the relevant ports,

bacula-7.4.0
check-0.10.0
check_mssql_health-1.5.19
clusterit-2.5
djview4-4.10.6
elinks-0.11.7
freedroidrpg-0.16
geda-gaf-1.6.0
kea-1.0.0
lam-6.5.9
latex-mk-1.9.1
lbdb_0.40
libgnome-2.32.1
libgnomecanvas-2.30.3
libgnomeui-2.24.5
libreoffice-5.1.2.2
libsmi-0.4.8
quilt-0.64
xboard-4.8.0

basic diff:

Index: config.no-gawk
===
RCS file: /cvs/ports/infrastructure/db/config.no-gawk,v
retrieving revision 1.1
diff -u -p -r1.1 config.no-gawk
--- config.no-gawk  12 Dec 2011 10:33:33 -  1.1
+++ config.no-gawk  27 Jun 2016 19:32:34 -
@@ -1,3 +1,4 @@
 # $OpenBSD: config.no-gawk,v 1.1 2011/12/12 10:33:33 jasper Exp $
 # included unless lang/gawk
 ac_cv_prog_AWK=${ac_cv_prog_AWK=/usr/bin/awk}
+ac_cv_path_AWK=${ac_cv_path_AWK=/usr/bin/awk}

...but there's also this in config.site, which seems incorrect:

ac_cv_prog_AWK=${ac_cv_prog_AWK=awk}

Re: net/kea: Ensure base awk is used

[David Coppa]

On Mon, Jun 27, 2016 at 6:26 PM, Stuart Henderson  wrote:

> Perhaps we should add the path variant to config.site then..

It looks like the right approach to me, ok dcoppa@.

ciao!
David

Re: net/kea: Helpfully failing test in ./configure

[Jeremie Courreges-Anglas]

Patrik Lundin <pat...@sigterm.se> writes:

> Hello,
>
> When looking at the output of ./configure in net/kea I noticed the
> following warning which I have previously missed:
> ===
> ./configure[15929]: test: <: unexpected operator/operand
> ===
>
> The responsible code in the configure script should be this:
> ===
> # gcc 4.4 would emit warnings about breaking strict aliasing rules.
> # See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874
> CXX_DUMP_VERSION=`$CXX -dumpversion | cut -f1-2 -d.`
> if test "$CXX_DUMP_VERSION" \< "4.5"; then
>WARNING_GCC_44_STRICT_ALIASING_CFLAG="-fno-strict-aliasing"
> fi
> ===
>
> The error message is thrown because the builtin test does not support
> the "<" operator (which /bin/test does).
>
> The funny thing is that gcc in base does not seem to suffer from the
> bug that is described in the bug tracker linked above, because the build
> generates no warnings relating to strict-aliasing.
>
> This means that the failing "test" can actually be thought of as a
> feature. It is of course brittle, and will modify the build parameters
> if someone decides to teach the test builtin about "<" prior to bumping
> base gcc past 4.5.

This is a very unlikely scenario.

> Basically I am just asking for pointers from other porters, anyone have
> an idea how I should deal with this? Should I bother at all?

I guess you could just use /bin/test.

-- 
jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

net/kea: Helpfully failing test in ./configure

[Patrik Lundin]

Hello,

When looking at the output of ./configure in net/kea I noticed the
following warning which I have previously missed:
===
./configure[15929]: test: <: unexpected operator/operand
===

The responsible code in the configure script should be this:
===
# gcc 4.4 would emit warnings about breaking strict aliasing rules.
# See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874
CXX_DUMP_VERSION=`$CXX -dumpversion | cut -f1-2 -d.`
if test "$CXX_DUMP_VERSION" \< "4.5"; then
   WARNING_GCC_44_STRICT_ALIASING_CFLAG="-fno-strict-aliasing"
fi
===

The error message is thrown because the builtin test does not support
the "<" operator (which /bin/test does).

The funny thing is that gcc in base does not seem to suffer from the
bug that is described in the bug tracker linked above, because the build
generates no warnings relating to strict-aliasing.

This means that the failing "test" can actually be thought of as a
feature. It is of course brittle, and will modify the build parameters
if someone decides to teach the test builtin about "<" prior to bumping
base gcc past 4.5.

Basically I am just asking for pointers from other porters, anyone have
an idea how I should deal with this? Should I bother at all?

-- 
Patrik Lundin

Re: net/kea: Ensure base awk is used

[Stuart Henderson]

On 2016/06/27 17:19, Stuart Henderson wrote:
> On 2016/06/27 18:15, Patrik Lundin wrote:
> > +CONFIGURE_ENV+= ac_cv_path_AWK=awk
> 
> That should already be set. Is it not picking up config.site for some reason?
> 

Oh, it is ac_cv_*prog*_AWK that is getting set, for some reason kea
is also looking at ac_cv_*path*_AWK.

Perhaps we should add the path variant to config.site then..

net/kea: Ensure base awk is used

[Patrik Lundin]

Hello,

This diff solves a problem found by naddy@ where the build will fail if
gawk happens to be temporarily installed during a bulk build.

The fix was suggested by naddy@ as well, much appreciated!

It changes the output of a clean (no gawk installed) ./configure from:
===
checking for gawk... (cached) awk
checking for gawk... no
checking for awk... /usr/bin/awk
===

... to:
===
checking for gawk... (cached) awk
checking for gawk... (cached) awk
===

Without the diff and with gawk installed it looked like this:
===
checking for gawk... (cached) awk
checking for gawk... /usr/local/bin/gawk
===

I started an upstream discussion which can be found here:
https://lists.isc.org/pipermail/kea-users/2016-June/000416.html

Since upstream did not jump on this I feel it is good enough to fix it
this way for now.

Again, extra thanks to naddy@ for not only finding this bug but
also helping me wrap my head around the autoconf magic involved.

-- 
Patrik Lundin

Index: Makefile
===
RCS file: /cvs/ports/net/kea/Makefile,v
retrieving revision 1.5
diff -u -p -u -r1.5 Makefile
--- Makefile14 Mar 2016 06:46:24 -  1.5
+++ Makefile27 Jun 2016 15:55:51 -
@@ -3,6 +3,7 @@
 COMMENT=   high-performance and extensible DHCP server engine from ISC
 
 VERSION=   1.0.0
+REVISION=  0
 
 DISTNAME=  kea-${VERSION}
 PKGNAME=   ${DISTNAME:S/-P/pl/}
@@ -47,6 +48,7 @@ CONFIGURE_STYLE=  gnu
 CONFIGURE_ARGS+= --with-openssl=/usr \
  --with-boost-libs=-lboost_system \
  --with-boost-lib-dir=${LOCALBASE}/lib
+CONFIGURE_ENV+= ac_cv_path_AWK=awk
 
 LIBTOOL_FLAGS= --tag=disable-static
 

Re: net/kea: Ensure base awk is used

[Stuart Henderson]

On 2016/06/27 18:15, Patrik Lundin wrote:
> +CONFIGURE_ENV+= ac_cv_path_AWK=awk

That should already be set. Is it not picking up config.site for some reason?

net/kea: 1.0.0

[Patrik Lundin]

gory_const' referenced in 
section `.text' of .libs/libkea_asiolink_la-io_socket.o: defined in discarded 
section 
`.gnu.linkonce.b._ZZN5boost6system16generic_categoryEvE22generic_category_const'
 of .libs/libkea_asiolink_la-io_socket.o
`guard variable for boost::system::generic_category()::generic_category_const' 
referenced in section `.text' of .libs/libkea_asiolink_la-io_socket.o: defined 
in discarded section 
`.gnu.linkonce.b._ZGVZN5boost6system16generic_categoryEvE22generic_category_const'
 of .libs/libkea_asiolink_la-io_socket.o
`guard variable for boost::system::system_category()::system_category_const' 
referenced in section `.text' of .libs/libkea_asiolink_la-io_socket.o: defined 
in discarded section 
`.gnu.linkonce.b._ZGVZN5boost6system15system_categoryEvE21system_category_const'
 of .libs/libkea_asiolink_la-io_socket.o
collect2: ld returned 1 exit status
Error while executing c++ -shared -fPIC -DPIC -o .libs/libkea-asiolink.so.0.0 
-pthread -Wall -Wextra -Wnon-virtual-dtor -Wwrite-strings -Woverloaded-virtual 
-Wno-sign-compare -fPIC -O2 -pipe .libs/libkea_asiolink_la-interval_timer.o 
.libs/libkea_asiolink_la-io_address.o .libs/libkea_asiolink_la-io_endpoint.o 
.libs/libkea_asiolink_la-io_service.o .libs/libkea_asiolink_la-io_socket.o 
-L.libs -lpthread -lkea-exceptions
*** Error 2 in src/lib/asiolink (Makefile:543 'libkea-asiolink.la')
*** Error 1 in src/lib/asiolink (Makefile:672 'all-recursive')
*** Error 1 in src/lib (Makefile:426 'all-recursive')
*** Error 1 in src (Makefile:428 'all-recursive')
*** Error 1 in . (Makefile:595 'all-recursive')
*** Error 1 in /home/usr/ports/pobj/kea-1.0.0/kea-1.0.0 (Makefile:436 'all')
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2773 
'/usr/ports/pobj/kea-1.0.0/.build_done')
*** Error 1 in /usr/ports/net/kea 
(/usr/ports/infrastructure/mk/bsd.port.mk:2495 'build')
===

Some digging led me to this ticket http://kea.isc.org/ticket/4009
which in turn led me to the configure flags for defining what boost library to
use. After adding the additional configure flags the build succeeded.

Highlights:
* Renames "message" binary to "kea-msg-compiler".
* Removes all the "include/kea/asio/" stuff.
* Promotes the BUILD_DEPEND of devel/boost to a LIB_DEPEND (which i
  guess is good since it appears to clean up the include stuff above).
* Adds an additional SHARED_LIB (kea-eval).

The diff to CVS below, let me know what you think.

-- 
Patrik Lundin

Index: Makefile
===========
RCS file: /cvs/ports/net/kea/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile23 Dec 2015 15:58:55 -  1.3
+++ Makefile30 Dec 2015 04:16:29 -
@@ -4,11 +4,10 @@ SHARED_ONLY=  Yes
 
 COMMENT=   high-performance and extensible DHCP server engine from ISC
 
-VERSION=   0.9.2-P1
+VERSION=   1.0.0
 
 DISTNAME=  kea-${VERSION}
 PKGNAME=   ${DISTNAME:S/-P/pl/}
-REVISION=  0
 
 SHARED_LIBS +=  kea-asiodns   0.0 # 0.0
 SHARED_LIBS +=  kea-asiolink  0.0 # 2.0
@@ -19,6 +18,7 @@ SHARED_LIBS +=  kea-dhcp++  
 SHARED_LIBS +=  kea-dhcp_ddns 0.0 # 1.0
 SHARED_LIBS +=  kea-dhcpsrv   0.0 # 4.0
 SHARED_LIBS +=  kea-dns++ 0.0 # 2.0
+SHARED_LIBS +=  kea-eval  0.0 # 3.0
 SHARED_LIBS +=  kea-exceptions0.0 # 0.0
 SHARED_LIBS +=  kea-hooks 0.0 # 1.0
 SHARED_LIBS +=  kea-log   0.0 # 1.0
@@ -33,20 +33,22 @@ HOMEPAGE=   http://kea.isc.org/
 
 MAINTAINER=Patrik Lundin <pat...@sigterm.se>
 
-# ISC (XXX Kea 1.0 changes to MPL)
+# MPL 2.0
 PERMIT_PACKAGE_CDROM=  Yes
 
-WANTLIB += c crypto log4cplus m pthread stdc++
+WANTLIB += boost_system c crypto log4cplus m pthread stdc++
 
 MASTER_SITES=  ${MASTER_SITE_ISC:=kea/${VERSION}/}
 
-BUILD_DEPENDS= devel/boost
-LIB_DEPENDS=   devel/log4cplus
+LIB_DEPENDS=   devel/boost \
+   devel/log4cplus
 
 FAKE_FLAGS=sysconfdir=${PREFIX}/share/examples
 
 CONFIGURE_STYLE=   gnu
-CONFIGURE_ARGS+= --with-openssl=/usr
+CONFIGURE_ARGS+= --with-openssl=/usr \
+ --with-boost-libs=-lboost_system \
+ --with-boost-lib-dir=${LOCALBASE}/lib
 
 LIBTOOL_FLAGS= --tag=disable-static
 
Index: distinfo
===========
RCS file: /cvs/ports/net/kea/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo23 Dec 2015 13:40:53 -  1.1.1.1
+++ distinfo30 Dec 2015 04:16:29 -
@@ -1,2 +1,2 @@
-SHA256 (kea-0.9.2-P1.tar.gz) = Ne4gqNW0/FCU6d7d2YnuJ3TXIcCdU9/WS2QIr2P3md4=
-SIZE (kea-0.9.2-P1.tar.gz) = 4436468
+SHA256 (kea-1.0.0.tar.gz) = lphP6Rj5Ez0I0xFerAEtKIFNjM+vJSiUmfAo3lYTWv4=
+SIZE (kea-1.0.0.tar.gz) = 4559334
Index: pkg/PLIST
===========
RCS file: /cvs/ports/net/kea/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u 

Re: net/kea

[Patrik Lundin]

On Thu, Dec 24, 2015 at 02:53:06AM +, Stuart Henderson wrote:
> 
> I saw it on oss-sec first, then on ISC's security RSS feed (and as if
> to emphasize the slightly random nature of that feed it was followed
> by release notes for 0.9, 0.9.2-beta and 0.9.2 :-) I read oss-sec anyway,
> and since I maintain the BIND port I track a few places where ISC are
> likely to announce things.
> 
> http://www.openwall.com/lists/oss-security/2015/12/22/11
> https://www.isc.org/?feed=security-feed
> 

Thanks for the info, I guess it is time to spin up newsbeuter again :).

-- 
Patrik Lundin

Re: net/kea

[Stuart Henderson]

Updated tar.gz for the 0.9.2-P1 crash fix ("Improved handling of incoming
packets with invalid client-id and DUID.") I also added an XXX comment
to remind us to update the license marker for 1.0 because ISC are moving
to the Apache license :'(

I'm still looking for OKs to import if anyone has time to look it over...


On 2015/12/10 09:57, Stuart Henderson wrote:
> On 2015/12/09 20:33, Patrik Lundin wrote:
> > On Tue, Dec 08, 2015 at 11:15:04PM +, Stuart Henderson wrote:
> > > On 2015/12/08 23:59, Patrik Lundin wrote:
> > > > I have posted a question to kea-dev regarding this:
> > > > https://lists.isc.org/pipermail/kea-dev/2015-December/000588.html
> > > > 
> > > > Let's see how that goes.
> > > 
> > > Good idea.
> > > 
> > 
> > I have recieved a response now. As I do not think there is an
> > overwhelming reason for using Botan I feel it is nicer to skip
> > additional port dependencies and explicitly use our LibreSSL instead.
> > 
> > The question remaining is if the configure flag should be --with-openssl
> > or --with-openssl=/usr. While it seems the configure script will look
> > for the library in an order that starts with /usr, I wonder if it is
> > nicer to be explicit that we want to use the base version (rather than
> > the openssl port for instance).
> > 
> > Attached is a port with the explicit flag set and a shortened
> > LIB_DEPENDS/WANTLIB list. I have tested that it ignores the use of Botan
> > when it is installed. Let me know what you think.
> 
> Either way is OK, I deliberately put the ports version of OpenSSL in a
> directory that is unlikely to be searched by configure. (Unless it uses
> something like the bonkers locate(1) check that freeradius3 uses, but
> I digress...)
> 
> Any OKs to import this version?
> 



kea,4.tgz
Description: application/tar-gz

Re: net/kea

[Landry Breuil]

On Wed, Dec 23, 2015 at 11:33:30AM +, Stuart Henderson wrote:
> Updated tar.gz for the 0.9.2-P1 crash fix ("Improved handling of incoming
> packets with invalid client-id and DUID.") I also added an XXX comment
> to remind us to update the license marker for 1.0 because ISC are moving
> to the Apache license :'(
> 
> I'm still looking for OKs to import if anyone has time to look it over...

Quickly skimmed through it, only two small remarks:
include/kea/asio/ -> this looks like a partial copy of boost's
boost/asio library ? patched ? copied ? what for ?

bin/message in PLIST seems awfully generic, but luckily it doesnt
conflict with anything in pkglocatedb...

Other than that, looks good to me.

Landry

Re: net/kea

[Patrik Lundin]

On Wed, Dec 23, 2015 at 11:33:30AM +, Stuart Henderson wrote:
> Updated tar.gz for the 0.9.2-P1 crash fix ("Improved handling of incoming
> packets with invalid client-id and DUID.")
>

Nice catch! I had not seen any word of this release on the kea mailing
lists, how did you notice it?

>
> I also added an XXX comment
> to remind us to update the license marker for 1.0 because ISC are moving
> to the Apache license :'(
> 

I did have this upcoming change noted in the back of my head, but having
an explicit note in the Makefile does makes sense.

-- 
Patrik Lundin

Re: net/kea

[Kenneth Westerback]

On 23 December 2015 at 21:53, Stuart Henderson  wrote:
> On 2015/12/23 14:47, Patrik Lundin wrote:
>> On Wed, Dec 23, 2015 at 11:33:30AM +, Stuart Henderson wrote:
>> > Updated tar.gz for the 0.9.2-P1 crash fix ("Improved handling of incoming
>> > packets with invalid client-id and DUID.")
>> >
>>
>> Nice catch! I had not seen any word of this release on the kea mailing
>> lists, how did you notice it?
>
> I saw it on oss-sec first, then on ISC's security RSS feed (and as if
> to emphasize the slightly random nature of that feed it was followed
> by release notes for 0.9, 0.9.2-beta and 0.9.2 :-) I read oss-sec anyway,
> and since I maintain the BIND port I track a few places where ISC are
> likely to announce things.
>
> http://www.openwall.com/lists/oss-security/2015/12/22/11
> https://www.isc.org/?feed=security-feed
>

What would be really  nice is if they described somewhere the
'crafted' packet that was blowing them up. As far as the diff goes
they just wrapped try {} around the code trying to get a client
identifier. So it's kinda unsatisfying as far as figuring out if our
in-tree dhcpd would blow up with a similar packet. :-)

 Ken

Re: net/kea

[Stuart Henderson]

On 2015/12/23 14:47, Patrik Lundin wrote:
> On Wed, Dec 23, 2015 at 11:33:30AM +, Stuart Henderson wrote:
> > Updated tar.gz for the 0.9.2-P1 crash fix ("Improved handling of incoming
> > packets with invalid client-id and DUID.")
> >
> 
> Nice catch! I had not seen any word of this release on the kea mailing
> lists, how did you notice it?

I saw it on oss-sec first, then on ISC's security RSS feed (and as if
to emphasize the slightly random nature of that feed it was followed
by release notes for 0.9, 0.9.2-beta and 0.9.2 :-) I read oss-sec anyway,
and since I maintain the BIND port I track a few places where ISC are
likely to announce things.

http://www.openwall.com/lists/oss-security/2015/12/22/11
https://www.isc.org/?feed=security-feed

Re: net/kea

[Stuart Henderson]

On 2015/12/23 22:03, Kenneth Westerback wrote:
> On 23 December 2015 at 21:53, Stuart Henderson  wrote:
> > On 2015/12/23 14:47, Patrik Lundin wrote:
> >> On Wed, Dec 23, 2015 at 11:33:30AM +, Stuart Henderson wrote:
> >> > Updated tar.gz for the 0.9.2-P1 crash fix ("Improved handling of incoming
> >> > packets with invalid client-id and DUID.")
> >> >
> >>
> >> Nice catch! I had not seen any word of this release on the kea mailing
> >> lists, how did you notice it?
> >
> > I saw it on oss-sec first, then on ISC's security RSS feed (and as if
> > to emphasize the slightly random nature of that feed it was followed
> > by release notes for 0.9, 0.9.2-beta and 0.9.2 :-) I read oss-sec anyway,
> > and since I maintain the BIND port I track a few places where ISC are
> > likely to announce things.
> >
> > http://www.openwall.com/lists/oss-security/2015/12/22/11
> > https://www.isc.org/?feed=security-feed
> >
> 
> What would be really  nice is if they described somewhere the
> 'crafted' packet that was blowing them up. As far as the diff goes
> they just wrapped try {} around the code trying to get a client
> identifier. So it's kinda unsatisfying as far as figuring out if our
> in-tree dhcpd would blow up with a similar packet. :-)

See, they learned from Juniper!

Re: net/kea

[Stuart Henderson]

On 2015/12/09 20:33, Patrik Lundin wrote:
> On Tue, Dec 08, 2015 at 11:15:04PM +, Stuart Henderson wrote:
> > On 2015/12/08 23:59, Patrik Lundin wrote:
> > > I have posted a question to kea-dev regarding this:
> > > https://lists.isc.org/pipermail/kea-dev/2015-December/000588.html
> > > 
> > > Let's see how that goes.
> > 
> > Good idea.
> > 
> 
> I have recieved a response now. As I do not think there is an
> overwhelming reason for using Botan I feel it is nicer to skip
> additional port dependencies and explicitly use our LibreSSL instead.
> 
> The question remaining is if the configure flag should be --with-openssl
> or --with-openssl=/usr. While it seems the configure script will look
> for the library in an order that starts with /usr, I wonder if it is
> nicer to be explicit that we want to use the base version (rather than
> the openssl port for instance).
> 
> Attached is a port with the explicit flag set and a shortened
> LIB_DEPENDS/WANTLIB list. I have tested that it ignores the use of Botan
> when it is installed. Let me know what you think.

Either way is OK, I deliberately put the ports version of OpenSSL in a
directory that is unlikely to be searched by configure. (Unless it uses
something like the bonkers locate(1) check that freeradius3 uses, but
I digress...)

Any OKs to import this version?

Re: net/kea

[Mike]

On 12/8/2015 5:41 PM, Patrik Lundin wrote:
> On Tue, Dec 08, 2015 at 11:18:53PM +0100, Patrik Lundin wrote:
>>
>> What is picking up botan? I looked at every @bin and @lib with ldd and I
>> can't see anyone referring to that library. What am i missing?
>>
> 
>>From http://kea.isc.org/docs/kea-guide.html#required-software:
> ===
> Kea supports two crypto libraries: Botan and OpenSSL. Only one of them
> is required to be installed during compilation. Kea uses the Botan
> crypto library for C++ (http://botan.randombit.net/), version 1.8 or
> later. As an alternative to Botan, Kea can use the OpenSSL crypto
> library (http://www.openssl.org/). It requires a version with SHA-2
> support. 
> ===
> 
> I realize I do not know which library is preferred from the upstream
> perspective, but using LibreSSL seemed nice (and this is what was choosen on 
> my
> build box).
> 
> On my box the following is seen:
> ===
> # ldd /usr/local/sbin/kea-dhcp4
> [...]
> 1f4847a77000 1f4848045000 rlib 07   0  
> /usr/lib/libcrypto.so.36.1
> [...]
> ===
> 
>>From config.log (after tests for botan have failed):
> ===
> configure:17410: checking for OpenSSL library
> configure:17430: result: yes
> configure:17468: checking OpenSSL version
> configure:17480: result: LibreSSL 2.3.2
> configure:17485: checking support of SHA-2
> configure:17506: c++ -o conftest -O2 -pipe   -DOS_BSD  conftest.cpp  -lcrypto 
> >&5
> configure:17506: $? = 0
> configure:17507: result: yes
> ===
> 
> I can ask upstream what they prefer if there are no strong opinions raised on
> this list.
> 

One of the reasons I am moving back to OpenBSD (now that rtadv and IPv6
forwarding are now supported simultaneously) is due to things like
LibreSSL, and the thought and code quality behind it.

If upstream doesn't have a strong preference, please go to LibreSSL.

thx.

Re: net/kea

[Patrik Lundin]

On Tue, Dec 08, 2015 at 11:15:04PM +, Stuart Henderson wrote:
> On 2015/12/08 23:59, Patrik Lundin wrote:
> > I have posted a question to kea-dev regarding this:
> > https://lists.isc.org/pipermail/kea-dev/2015-December/000588.html
> > 
> > Let's see how that goes.
> 
> Good idea.
> 

I have recieved a response now. As I do not think there is an
overwhelming reason for using Botan I feel it is nicer to skip
additional port dependencies and explicitly use our LibreSSL instead.

The question remaining is if the configure flag should be --with-openssl
or --with-openssl=/usr. While it seems the configure script will look
for the library in an order that starts with /usr, I wonder if it is
nicer to be explicit that we want to use the base version (rather than
the openssl port for instance).

Attached is a port with the explicit flag set and a shortened
LIB_DEPENDS/WANTLIB list. I have tested that it ignores the use of Botan
when it is installed. Let me know what you think.

-- 
Patrik Lundin


kea,3.tgz
Description: application/tar-gz

Re: net/kea

[Patrik Lundin]

On Wed, Dec 09, 2015 at 08:33:10PM +0100, Patrik Lundin wrote:
> 
> Attached is a port with the explicit flag set and a shortened
> LIB_DEPENDS/WANTLIB list. I have tested that it ignores the use of Botan
> when it is installed. Let me know what you think.
> 

Stuart: It would of course be nice to know if this stops the inclusion of
Botan on your build box as well, just for good measure.

-- 
Patrik Lundin

Re: net/kea

[Patrik Lundin]

On Tue, Dec 08, 2015 at 07:39:24PM +0100, Patrik Lundin wrote:
> > not a port problem, but "message" is a terrible name for sonething that
> > upstream want to place in a system directory!
> 
> I have mentioned this in my upstream kea-dev thread.
> 

FYI: upstream has created a ticket which aims to rename "message" to
"kea-msg-compiler" based on this input: http://kea.isc.org/ticket/4228

-- 
Patrik Lundin

Re: net/kea

[Patrik Lundin]

On Mon, Dec 07, 2015 at 09:59:44AM +, Stuart Henderson wrote:
> > 
> > 1. When running "make update-plist" I get the following messages:
> > ===
> > make-plist: Bogus element outside of every prefix: /etc/kea/kea.conf
> > make-plist: Bogus element outside of every prefix: /etc/kea/keactrl.conf
> 
> For these, you can often override a variable in upstream's Makefiles
> in FAKE_FLAGS to install these files to /usr/local/share/examples,
> often named sysconfdir or SYSCONFDIR.
> 
>  it's likely to be similar to this
> 
> FAKE_FLAGS= sysconfdir=${PREFIX}/share/examples/
> 
> pre-install:
> mkdir -p ${PREFIX}/share/examples/bind10/
> 

Some trial and error proved that these were pretty much exactly what was
needed, thanks!

This line is now printed instead, guess I can just ignore it?:
===
make-plist: Bogus element outside of every prefix: /etc/kea
===

> > make-plist: Bogus element outside of every prefix: /etc/rc.d/kea
> 
> Ignore this and handle the rcscript in PLIST manually.
> 

I have noticed that update-plist always removes the rcscript in
PLIST, but reading older threads this seems to be a known problem.

> > make-plist: Bogus element outside of every prefix: /var/kea
> > make-plist: Bogus element outside of every prefix: /var/run/kea
> 
> /var/run is cleared at boot so the /var/run/kea directory needs creating
> in the rcscript. we normally do not include these in plist.
> 

I have removed the PLIST @sample for /var/run/kea, and added an rc_pre()
which creates the directory if it does not exist.

> 
> other comments:
> 
> "@sample /etc/kea/" shoukd use SYSCONFDIR and this plist line is usually
> placed near the files that go in that dir
> 

Fixed.

>
> please order Makefile closer to the section ordering in
> Makefile.template
> 
> the shared libs lines are ok (except want to be earlier in the makefile)
> 

I have done a major reorder of the Makefile to mirror the template.

> the static libs are unlikely to be useful, and the whole port is unlikely
> to work without shared libs, so I'd disable them (probably --disable-static
> in CONFIGURE_ARGS, and SHARED_ONLY=Yes) to save build time
> 

This turned out to be the trickiest part. Adding "--disable-static" to
CONFIGURE_ARGS indeed disabled static libraries according to config.log:
===
configure:12388: checking whether to build static libraries
configure:12392: result: no
===

However, the .a files were still being generated by the build.

After digging around I found out about LIBTOOL_FLAGS and added
"LIBTOOL_FLAGS=  --tag=disable-static" and this made the .a files
disappear.

Using LIBTOOL_FLAGS it does not seem to matter if CONFIGURE_ARGS are set
or not, should I use both for good measure or only LIBTOOL_FLAGS? Is
this expected behaviour?

> not a port problem, but "message" is a terrible name for sonething that
> upstream want to place in a system directory!

I have mentioned this in my upstream kea-dev thread.

Attached is the updated port, which only uses LIBTOOL_FLAGS to disable
the static libraries.

Thanks a lot for your time!

-- 
Patrik Lundin


kea.tgz
Description: application/tar-gz

Re: net/kea

[Patrik Lundin]

On Tue, Dec 08, 2015 at 10:41:07PM +, Stuart Henderson wrote:
> 
> I see it in perfdhcp. Actually it looks like there's another option, we can
> instead use CONFIGURE_ARGS+= --with-openssl - which would you prefer?
> 
> $ objdump -p ../fake-amd64/usr/local/sbin/perfdhcp
> 
[...]
>   NEEDED  libbotan-1.10.so.1.0
[...]

It is not being required on my (clean) system, did you have the library
installed previously when building the port? Of course we should make sure only
one path is choosen anyway.

For reference, this is how perfdhcp looks for me:
===
# objdump -p /usr/local/sbin/perfdhcp  

/usr/local/sbin/perfdhcp: file format elf64-x86-64

Program Header:
PHDR off0x0040 vaddr 0x0040 paddr 
0x0040 align 2**3
 filesz 0x0268 memsz 0x0268 flags r-x
  INTERP off0x0318 vaddr 0x0318 paddr 
0x0318 align 2**0
 filesz 0x0013 memsz 0x0013 flags r--
LOAD off0x vaddr 0x paddr 
0x align 2**20
 filesz 0x0005361e memsz 0x0005361e flags r-x
LOAD off0x00053620 vaddr 0x00153620 paddr 
0x00153620 align 2**20
 filesz 0x00011ae5 memsz 0x00011ae5 flags r--
LOAD off0x00065108 vaddr 0x00265108 paddr 
0x00265108 align 2**20
 filesz 0x1ad0 memsz 0x1ad0 flags rw-
LOAD off0x00066bd8 vaddr 0x00366bd8 paddr 
0x00366bd8 align 2**20
 filesz 0x0908 memsz 0x0908 flags rw-
LOAD off0x000674e0 vaddr 0x004674e0 paddr 
0x004674e0 align 2**20
 filesz 0x0058 memsz 0x0500 flags rw-
 DYNAMIC off0x00066a08 vaddr 0x00266a08 paddr 
0x00266a08 align 2**3
 filesz 0x01d0 memsz 0x01d0 flags rw-
NOTE off0x032c vaddr 0x032c paddr 
0x032c align 2**2
 filesz 0x0018 memsz 0x0018 flags r--
EH_FRAME off0x0005a128 vaddr 0x0015a128 paddr 
0x0015a128 align 2**2
 filesz 0x0f54 memsz 0x0f54 flags r--
OPENBSD_RANDOMIZE off0x00065108 vaddr 0x00265108 paddr 
0x00265108 align 2**3
 filesz 0x0008 memsz 0x0008 flags rw-

Dynamic Section:
  NEEDED  libkea-exceptions.so.0.0
  NEEDED  libkea-dhcp++.so.0.0
  NEEDED  libkea-asiolink.so.0.0
  NEEDED  libkea-dns++.so.0.0
  NEEDED  libkea-cryptolink.so.0.0
  NEEDED  libcrypto.so.36.1
  NEEDED  libkea-util.so.0.0
  NEEDED  libstdc++.so.57.0
  NEEDED  libm.so.9.0
  NEEDED  libc.so.84.2
  HASH0x348
  STRTAB  0x48f0
  SYMTAB  0x1440
  STRSZ   0x69e5
  SYMENT  0x18
  DEBUG   0x0
  PLTGOT  0x366bd8
  PLTRELSZ0xd98
  PLTREL  0x7
  JMPREL  0xf700
  RELA0xb2d8
  RELASZ  0x4428
  RELAENT 0x18
  RELACOUNT   0x111

===

I have posted a question to kea-dev regarding this:
https://lists.isc.org/pipermail/kea-dev/2015-December/000588.html

Let's see how that goes.

-- 
Patrik Lundin

Re: net/kea

[Patrik Lundin]

On Tue, Dec 08, 2015 at 11:18:53PM +0100, Patrik Lundin wrote:
> 
> What is picking up botan? I looked at every @bin and @lib with ldd and I
> can't see anyone referring to that library. What am i missing?
> 

>From http://kea.isc.org/docs/kea-guide.html#required-software:
===
Kea supports two crypto libraries: Botan and OpenSSL. Only one of them
is required to be installed during compilation. Kea uses the Botan
crypto library for C++ (http://botan.randombit.net/), version 1.8 or
later. As an alternative to Botan, Kea can use the OpenSSL crypto
library (http://www.openssl.org/). It requires a version with SHA-2
support. 
===

I realize I do not know which library is preferred from the upstream
perspective, but using LibreSSL seemed nice (and this is what was choosen on my
build box).

On my box the following is seen:
===
# ldd /usr/local/sbin/kea-dhcp4
[...]
1f4847a77000 1f4848045000 rlib 07   0  
/usr/lib/libcrypto.so.36.1
[...]
===

>From config.log (after tests for botan have failed):
===
configure:17410: checking for OpenSSL library
configure:17430: result: yes
configure:17468: checking OpenSSL version
configure:17480: result: LibreSSL 2.3.2
configure:17485: checking support of SHA-2
configure:17506: c++ -o conftest -O2 -pipe   -DOS_BSD  conftest.cpp  -lcrypto 
>&5
configure:17506: $? = 0
configure:17507: result: yes
===

I can ask upstream what they prefer if there are no strong opinions raised on
this list.

-- 
Patrik Lundin

Re: net/kea

[Stuart Henderson]

On 2015/12/08 23:18, Patrik Lundin wrote:
> On Tue, Dec 08, 2015 at 09:46:34PM +, Stuart Henderson wrote:
> > Thanks, this is looking good to me, Only two changes I'd make. First is
> > in the rc script, what you have isn't wrong, but the mkdir/chown/chmod
> > lines can be replaced with a single command:
> > 
> > install -d -o root:_kea -m 775 ${LOCALSTATEDIR}/run/kea
> > 
> 
> This is much prettier, nice catch :).
> 
> >
> > Second change is WANTLIB/LIB_DEPENDS; it picks up botan so it needs to be
> > listed in LIB_DEPENDS, and the relevant WANTLIBs added. New tar attached.
> > 
> 
> What is picking up botan? I looked at every @bin and @lib with ldd and I
> can't see anyone referring to that library. What am i missing?
> 
> -- 
> Patrik Lundin
> 

I see it in perfdhcp. Actually it looks like there's another option, we can
instead use CONFIGURE_ARGS+= --with-openssl - which would you prefer?



$ objdump -p ../fake-amd64/usr/local/sbin/perfdhcp

../fake-amd64/usr/local/sbin/perfdhcp: file format elf64-x86-64

Program Header:
PHDR off0x0040 vaddr 0x0040 paddr 
0x0040 align 2**3
 filesz 0x0268 memsz 0x0268 flags r-x
  INTERP off0x0318 vaddr 0x0318 paddr 
0x0318 align 2**0
 filesz 0x0013 memsz 0x0013 flags r--
LOAD off0x vaddr 0x paddr 
0x align 2**20
 filesz 0x000536de memsz 0x000536de flags r-x
LOAD off0x000536e0 vaddr 0x001536e0 paddr 
0x001536e0 align 2**20
 filesz 0x00011ba5 memsz 0x00011ba5 flags r--
LOAD off0x00065288 vaddr 0x00265288 paddr 
0x00265288 align 2**20
 filesz 0x1b30 memsz 0x1b30 flags rw-
LOAD off0x00066db8 vaddr 0x00366db8 paddr 
0x00366db8 align 2**20
 filesz 0x0908 memsz 0x0908 flags rw-
LOAD off0x000676c0 vaddr 0x004676c0 paddr 
0x004676c0 align 2**20
 filesz 0x0058 memsz 0x0500 flags rw-
 DYNAMIC off0x00066b88 vaddr 0x00266b88 paddr 
0x00266b88 align 2**3
 filesz 0x0230 memsz 0x0230 flags rw-
NOTE off0x032c vaddr 0x032c paddr 
0x032c align 2**2
 filesz 0x0018 memsz 0x0018 flags r--
EH_FRAME off0x0005a2a8 vaddr 0x0015a2a8 paddr 
0x0015a2a8 align 2**2
 filesz 0x0f54 memsz 0x0f54 flags r--
OPENBSD_RANDOMIZE off0x00065288 vaddr 0x00265288 paddr 
0x00265288 align 2**3
 filesz 0x0008 memsz 0x0008 flags rw-

Dynamic Section:
  NEEDED  libkea-exceptions.so.0.0
  NEEDED  libkea-dhcp++.so.0.0
  NEEDED  libkea-asiolink.so.0.0
  NEEDED  libkea-dns++.so.0.0
  NEEDED  libkea-cryptolink.so.0.0
  NEEDED  libbotan-1.10.so.1.0
  NEEDED  libbz2.so.10.4
  NEEDED  libcrypto.so.36.1
  NEEDED  libgmp.so.9.0
  NEEDED  libpthread.so.20.1
  NEEDED  libz.so.5.0
  NEEDED  libkea-util.so.0.0
  NEEDED  libstdc++.so.57.0
  NEEDED  libm.so.9.0
  NEEDED  libc.so.84.2
  RPATH   /usr/local/lib
  HASH0x348
  STRTAB  0x4908
  SYMTAB  0x1440
  STRSZ   0x6a93
  SYMENT  0x18
  DEBUG   0x0
  PLTGOT  0x366db8
  PLTRELSZ0xd98
  PLTREL  0x7
  JMPREL  0xf7c8
  RELA0xb3a0
  RELASZ  0x4428
  RELAENT 0x18
  RELACOUNT   0x111

Re: net/kea

[Stuart Henderson]

On 2015/12/08 23:59, Patrik Lundin wrote:
> On Tue, Dec 08, 2015 at 10:41:07PM +, Stuart Henderson wrote:
> > 
> > I see it in perfdhcp. Actually it looks like there's another option, we can
> > instead use CONFIGURE_ARGS+= --with-openssl - which would you prefer?
> > 
> > $ objdump -p ../fake-amd64/usr/local/sbin/perfdhcp
> > 
> [...]
> >   NEEDED  libbotan-1.10.so.1.0
> [...]
> 
> It is not being required on my (clean) system, did you have the library
> installed previously when building the port? Of course we should make sure 
> only
> one path is choosen anyway.

Yes - and this will sometimes be the case in package builds, so if it's not
registered then we'll either have build failures (DPB has a 'junking' stage
run periodically where it removes packages during the build if they're not
a known dependency of anything currently being built) or runtime failures
(if packages are produced which are built against botan and the user doesn't
have that installed).

> I have posted a question to kea-dev regarding this:
> https://lists.isc.org/pipermail/kea-dev/2015-December/000588.html
> 
> Let's see how that goes.

Good idea.

Re: net/kea

[Patrik Lundin]

On Tue, Dec 08, 2015 at 09:46:34PM +, Stuart Henderson wrote:
> Thanks, this is looking good to me, Only two changes I'd make. First is
> in the rc script, what you have isn't wrong, but the mkdir/chown/chmod
> lines can be replaced with a single command:
> 
>   install -d -o root:_kea -m 775 ${LOCALSTATEDIR}/run/kea
> 

This is much prettier, nice catch :).

>
> Second change is WANTLIB/LIB_DEPENDS; it picks up botan so it needs to be
> listed in LIB_DEPENDS, and the relevant WANTLIBs added. New tar attached.
> 

What is picking up botan? I looked at every @bin and @lib with ldd and I
can't see anyone referring to that library. What am i missing?

-- 
Patrik Lundin

Re: net/kea

[Stuart Henderson]

Thanks, this is looking good to me, Only two changes I'd make. First is
in the rc script, what you have isn't wrong, but the mkdir/chown/chmod
lines can be replaced with a single command:

install -d -o root:_kea -m 775 ${LOCALSTATEDIR}/run/kea

Second change is WANTLIB/LIB_DEPENDS; it picks up botan so it needs to be
listed in LIB_DEPENDS, and the relevant WANTLIBs added. New tar attached.

Any OKs to import? (Or, as usual, if someone else would like to import,
it's OK with me).

> FYI: upstream has created a ticket which aims to rename "message" to
> "kea-msg-compiler" based on this input: http://kea.isc.org/ticket/4228

Great, thanks :)



kea,2.tgz
Description: application/tar-gz

Re: net/kea

[Stuart Henderson]

On 2015/12/06 21:19, Patrik Lundin wrote:
> Hello,
> 
> I am working on a port for Kea, the new DHCP server from ISC.
> 
> ===
> # cat pkg/DESC
> Kea is a new open source DHCPv4/DHCPv6 server being developed by Internet
> Systems Consortium. The objective of this project is to provide a very
> high-performance, extensible DHCP server engine for use by enterprises and
> service providers, either as is or with extensions and modifications.
> 
> Kea provides DHCPv4 and DHCPv6 servers, a dynamic DNS update module, a 
> portable
> DHCP library, libdhcp++, and a DHCP benchmarking tool, perfdhcp.
> ===
> 
> Attached you will find the port, which is currently a work-in-progress
> hoping for input from more experience porters.
> 
> I am currently able to build three flavors: the default one which only
> uses the built in "memfile" backend, and then two database backends
> using mysql and postgresql.
> 
> My current up front questions are these:
> 
> 1. When running "make update-plist" I get the following messages:
> ===
> make-plist: Bogus element outside of every prefix: /etc/kea/kea.conf
> make-plist: Bogus element outside of every prefix: /etc/kea/keactrl.conf

For these, you can often override a variable in upstream's Makefiles
in FAKE_FLAGS to install these files to /usr/local/share/examples,
often named sysconfdir or SYSCONFDIR.

 it's likely to be similar to this

FAKE_FLAGS= sysconfdir=${PREFIX}/share/examples/

pre-install:
mkdir -p ${PREFIX}/share/examples/bind10/

the advantage of this is that if upstream later start to install another
file, you're less likely to miss it.

> make-plist: Bogus element outside of every prefix: /etc/rc.d/kea

Ignore this and handle the rcscript in PLIST manually.

> make-plist: Bogus element outside of every prefix: /var/kea
> make-plist: Bogus element outside of every prefix: /var/run/kea

/var/run is cleared at boot so the /var/run/kea directory needs creating
in the rcscript. we normally do not include these in plist.

> 
> Can these be ignored? I am handling all of the files mentioned via
> @sample lines in PLIST (except for rc.d/kea which of course is an @rc
> line).
> 
> 2. I am not completely comfortable in my SHARED_LIBS knowledge, I would
>appreciate an extra eye on those lines in the Makefile. Right now
>they are taken as-is from the output generated when building the
>port.
> 
> Other than that I have raised some additional questions against
> upstream, you can find them here:
> https://lists.isc.org/pipermail/kea-dev/2015-December/000576.html
> 
> -- 
> Patrik Lundin

other comments:

"@sample /etc/kea/" shoukd use SYSCONFDIR and this plist line is usually
placed near the files that go in that dir

please order Makefile closer to the section ordering in
Makefile.template

the shared libs lines are ok (except want to be earlier in the makefile)

the static libs are unlikely to be useful, and the whole port is unlikely
to work without shared libs, so I'd disable them (probably --disable-static
in CONFIGURE_ARGS, and SHARED_ONLY=Yes) to save build time

not a port problem, but "message" is a terrible name for sonething that
upstream want to place in a system directory!

net/kea

[Patrik Lundin]

Hello,

I am working on a port for Kea, the new DHCP server from ISC.

===
# cat pkg/DESC
Kea is a new open source DHCPv4/DHCPv6 server being developed by Internet
Systems Consortium. The objective of this project is to provide a very
high-performance, extensible DHCP server engine for use by enterprises and
service providers, either as is or with extensions and modifications.

Kea provides DHCPv4 and DHCPv6 servers, a dynamic DNS update module, a portable
DHCP library, libdhcp++, and a DHCP benchmarking tool, perfdhcp.
===

Attached you will find the port, which is currently a work-in-progress
hoping for input from more experience porters.

I am currently able to build three flavors: the default one which only
uses the built in "memfile" backend, and then two database backends
using mysql and postgresql.

My current up front questions are these:

1. When running "make update-plist" I get the following messages:
===
make-plist: Bogus element outside of every prefix: /etc/kea/kea.conf
make-plist: Bogus element outside of every prefix: /etc/kea/keactrl.conf
make-plist: Bogus element outside of every prefix: /etc/rc.d/kea
make-plist: Bogus element outside of every prefix: /var/kea
make-plist: Bogus element outside of every prefix: /var/run/kea
===

Can these be ignored? I am handling all of the files mentioned via
@sample lines in PLIST (except for rc.d/kea which of course is an @rc
line).

2. I am not completely comfortable in my SHARED_LIBS knowledge, I would
   appreciate an extra eye on those lines in the Makefile. Right now
   they are taken as-is from the output generated when building the
   port.

Other than that I have raised some additional questions against
upstream, you can find them here:
https://lists.isc.org/pipermail/kea-dev/2015-December/000576.html

-- 
Patrik Lundin


kea.tgz
Description: application/tar-gz