Permissions spec & Neutron driver

[Tomek Mrugalski]

On 15.07.2015 17:42, James Beedy wrote:
> I am implementing an ISC DHCP server driver for the Openstack Neutron
> project. My goal is to create a python module that controls, and allows
> multiple instances of ISC DHCP server to run under multiple different
> users. It would be nice if there was a spec that detailed the
Have you looked at Kea (http://kea.isc.org), ISC's new DHCP
implementation? While it is not yet as feature rich as the dhcpd, it has
a number of advantages that may be more useful for your purpose:

1. Kea allows on-line reconfiguration. You can update configuration
without shutting down the server.
2. The configuration file in JSON format. Processing JSON structures in
python should be straightforward. It should be much easier to generate
your configuration.
3. While Kea uses raw sockets by default, you can configure it to use
UDP sockets. That works well if all your traffic is coming through relay
agents. There are certain caveats, but this is something you may
investigate.
4. I do not know OpenStack infrastructure, but the only code that
requires root access is socket opening. This part of the code is nicely
structured to support different types of operation. We have regular UDP
sockets and specific implementations for LPF (Linux) and BPF (BSD
family). It should be relatively straightforward to implement something
else specific for OpenStack, if needed.
5. Kea's development is much faster, due to number of reasons: open
development (we have git repo on github), better code structure, lots of
unit-tests (2900+ and growing), good documentation (both user and
developer oriented) and also using modern techniques (C++, boost, tdd, ci).
6. Better performance. Want to hand out 7500 leases/sec? Sure.
7. Hooks. Do you want the server to do something unique? Have your own
lib do the magic trick.
8. Want to use CSV file to store your data? How about MySQL or Postgres?
Or maybe your own special database?

> files associated with the ISC DHCP server....as of right now I am
> playing a lot of guess and check, hopefully this is something you might
> be able to shed some light on. I am currently experimenting with running
> different instances of ISC DHCP server each in a chroot environment, but
> would like to not have to create a separate container or chroot for each
> instance of ISC DHCP server running on a box. I’m sure there is a more
> efficient way, I just am unfamiliar with the permissions spec. Any
> insight to the permissions associated with ISC DHCP server would be
> extremely appreciated. Also, is an ISC DHCP neutron driver something the
> ISC team has thought about, or possibly already has in the works somewhere? 
I can't speak for the ISC DHCP team, but as a Kea developer, I can tell
you about the situation in this project. We haven't actively worked on
OpenStack, simply because of time constraints. However, we'd love to see
the OpenStack support. We're warming up for our upcoming 1.0 release and
have our roadmap pretty must set for the next couple months. While it's
unlikely that we could develop anything major on our own, but we
definitely can review patches if you care to send any. We could also
give you some pointers, give tips or suggest various tricks.

On a related note, I just successfully run kea-dhcp4 (and kea-dhcp6,
too, if you care for IPv6) from regular account. For testing purposes,
kea can be told to listen on different than the regular, privileged
port. I told it to use UDP sockets ("dhcp-socket-type": "udp") and
listen on port 50000 (-p 50000 on command line). It's not really usable
in such mode (unless you reconfigure your relays to send traffic to
custom port), but it shows that opening sockets is the only major issue
that has to be solved and there should be no other gotchas.

If you're interested in this direction, let's continue this conversation
on the kea-dev mailing list
(https://lists.isc.org/mailman/listinfo/kea-dev).

Hope that helps.

Tomek Mrugalski
Kea developer, ISC