[Opendnssec-develop] Enforcer NG branch

[René Post]

Hi,

Just wanted to let you know about the progress that is being made w.r.t. the enforcer-ng.

Last week I created a new branch for the Enforcer NG code at svn+ssh://keihatsu.kirei.se/svn/dnssec/branches/OpenDNSSEC-enforcer-ng

The branch is a copy of the OpenDNSSEC 1.2 branch where an additional enforcer-ng directory contains the source code for the next generation enforcer.
The code is currently alpha and although it compiles and runs the key management is currently not complete.

The code has been verified to compile on MacOSX 10.6 and Linux (Ubuntu 11 and Debian) all on 64bit intel architectures.
The autoconf scripts use pkg-config to determine where google protocol buffers is installed. So both pkg-config as well as google protocol buffers are dependencies for the enforcer-ng.
The code that was generated for the protocol buffers expects to find protocol buffers 2.2.0 which comes standard on Ubuntu 10.
The code will work with more recent versions of protocol buffers, but int that case the C++ files need to be regenerated from the proto specification files using the protoc code generator that is part of google protocol buffers. The .proto files specify the data being processed by the enforcer as well as how this data is read in from XML files.
I've used the .rnc files that are part of the current OpenDNSSEC code base as leading in writing the .proto files and have added elements to the .rnc files where needed for the enforcer.

The daemon code, scheduler and shared code of the signer is used for the enforcer-ng. This code is taken from the recently restructured code for the signer (taken from the trunk).
The enforcer works the same way as the signer with a small (dumb) client program that connects to the daemon in order to be able to send it commands.

We have a milestone on the 2nd of may  2011 where we want to deliver a functional alpha version of the enforcer-ng.
That alpha will function but will have file based storage (to be precise serialized protocol buffer files).
For the beta that follows we will need to replace that file based storage with a database, along with figuring out how to convert the current database to  the new database.

Hopefully we'll have something generating real signer configs that can actually be processed by the signer somewhere at the end of this week.
In order for that to happen we need to do some more work on the enforcer engine itself as well as the key generation and management side.
What then remains is to implement some commands for settings flags like ds-seen etc. so that we hopefully have the enforcer working properly on the 2nd of may.

René