SECURITY UPDATE: net/kea. Tests/feedback needed.
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.co
Re: net/kea: 1.2.0
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
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
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
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
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
Re: net/kea: 1.2.0
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
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 +++
Re: net/kea: 1.1.0
Patrik Lundin 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
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
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 -VE
Re: net/kea: Ensure base awk is used
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
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
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
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
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
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
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
Patrik Lundin 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
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
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
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
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
in discarded section `.gnu.linkonce.b._ZZN5boost6system15system_categoryEvE21system_category_const' of .libs/libkea_asiolink_la-io_socket.o `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._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 -# 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
Re: net/kea
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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