Bug#759703: Questions about Kea
Hello Tomek,
On Fri, Jan 22, 2016 at 10:45:04PM +0100, Tomek Mrugalski wrote:
> On 22.01.2016 20:58, Adam Majer wrote:
> > Hi Tomasz,
> >
> > I'm packaging Kea right now, and hopefully I will have it ready by end
> > of the week. But I do have some questions and it would be beneficial
> > if you could answer them.
> Hi Adam!
>
> Great to hear that! I'll do my best to help.
>
> > 1. Currently Kea has one combined config file. Since I would like to
> > split the IPv4, Ipv6 and DDNS services into separate packages, is
> > there any potential problem in splitting the config file into three
> > distinct config files?
> That's not necessarily true. You could use one config file for all of
> them or three separate files if you want to. We provided a single config
> file, because it seems to be easier to maintain for users who installed
> from the source. But if you plan to split this into 3 packages, using 3
> separate configs seems perfectly fine.
Sounds good.
> On a related note, we're about to launch a kea-contrib repo on github.
> Let me know if there are any Debian specific files that you'd like us to
> host there. We'll put systemd scripts that were contributed by RedHat
> guys. I recently installed Debian 8 which seems to be using sysvinit.
> That's perfectly fine by me. I just wanted to mention that there are
> systemd scripts if they're of any use for you.
Systemd files are definitely prefererred especially if RedHat took the
time to define CapabilityBoundingSet and other security parameters. If
you can forward them, I'd appreciate it.
Systemd is Debian's default for next release, but I'll try to make
sure that things also work with SysV and Upstart. Debian likes to
support diversity :D
Debian-specific files most likely will end up at git.debian.org, but
kea-contrib could probably work too.
> > 2. Kea seem to be composed of a large number of dynamic
> > libraries. Is there any particular reason to ship these in separate
> > packages instead of one? Are there any libraries that are intended
> > for users and not just internal usage?
> libkea-dhcp++ seems to be the only library that could be useful as a
> standalone package. It provides generic DHCP operations, like open
> sockets, parse and build DHCP options and packets etc. It is currently
> used by DHCPv4 server, DHCPv6 server, dhcp-ddns daemon and perfdhcp
> (which is a performance tool).
>
> > Also, some of the libraries do not contain all the symbols that they
> > use. (you can use c++filt to change mangled names to readable ones)
> Thanks for this. I admit that I didn't know this tool. I will take a
> closer look. Due to family reasons, I won't be able to do this until Monday.
>
> I'm not sure how you want to proceed with this. Is this an issue that
> blocks the packaging process? Regardless if it does, we as ISC will do
> our best to fix the problem. I see that most all of the issues you
> listed below are in libkea-asiodns. This is a library we have inherited
> from (now dead) bind10 project.
The program runs, so it's not a problem. But if there are symbols that
are then not needed, then it smells like dead-code that can be cleaned
up.
So, initially I will just have all the libraries in a kea-common
package that contains all the libraries, for now. A wishlist type of a
bug from me would be for you guys to combine all the libraries into 1
or 2 .so files, instead of having more than a dozen, especially if
most are just internal. So maybe,
libdhcp++.so.
libkea.so.
Is such a thing possible in the future?
Then I could have
3 program packages (dhcpv4, dhcpv6, ddns)
admin package with the perf program and database scripts
2 library packages (4 actually, 2 are -dev)
documentation package (yes, guide is packaged)
For now, one big happy common library package :D
- Adam
--
Adam Majer
adamm@zombino.com
Reply to: