[Opendnssec-user] Announcing availability public beta-release of OpenDNSSEC 2.0

[Berry A.W. van Halderen]

Dear OpenDNSSEC community,

Today we enter the final steps towards the 2.0 release by handing out
the first real beta. The development is complete, testing has completed
and there are no bugs that would stop you replacing 1.4 with 2.0.

Download it here:
https://dist.opendnssec.org/source/testing/opendnssec-2.0.0b1.tar.gz

The new version presents a complete re-write of the enforcer, adding
some features and guarantees to not let your zone go bogus even when
modifying critical parameters.

Instead of focusing on the new we would like to know whether your
current uses are met with this release. This version is new and shiny,
has new things, but we have more in store. This as soon as we can
finalize this new baseline version that marks the final transition of
OpenDNSSEC to the NLNET Labs supported open source software.

We hope that with your feedback we can make rapid cycles towards a
quick final release. After the proper 2.0 release, we plan to have a
more incremental development schedule with several releases per year
with new features and bug fixes to prevent such a long cycle as 2.0 had.

Some heads-up when trying it out after being used to 1.4:
- Scripted migration from 1.4 to 2.0 is available, see MIGRATION file;
- Use command ods-enforcer-db-setup rather than "ods-ksmutil setup";
- Any other use of ods-ksmutil is replaced with the ods-enforcer
command, which requires the enforcer daemon to be running;
- Use ods-enforcer zone add and delete rather than modifying the
zonelist.xml file yourself. This file is not kept up-to-date
automatically anymore;
- to start using OpenDNSSEC, use ods-enforcer policy import instead
of update kasp to update your policies;
- Getting started at:
https://wiki.opendnssec.org/display/DOCS20/Quick+start+guide

Hope to hear from you,
the OpenDNSSEC team.

[Casper Gielen]

Post by Berry A.W. van Halderen
- Use ods-enforcer zone add and delete rather than modifying the
zonelist.xml file yourself. This file is not kept up-to-date
automatically anymore;

This doesn't fit well with my environment. I like configuration files as
they can be stored in a version control system and applied by a
configuration manager (eg Puppet).


It's not a big deal, I could write a wrapper that takes a configuration
file and make the appropriate calls to ods-enforcer add/remove, but the
old system worked fine for me.

[Berry A.W. van Halderen]

Post by Casper Gielen

Post by Berry A.W. van Halderen
- Use ods-enforcer zone add and delete rather than modifying the
zonelist.xml file yourself. This file is not kept up-to-date
automatically anymore;

This doesn't fit well with my environment. I like configuration files as
they can be stored in a version control system and applied by a
configuration manager (eg Puppet).
It's not a big deal, I could write a wrapper that takes a configuration
file and make the appropriate calls to ods-enforcer add/remove, but the
old system worked fine for me.

It is still possible at the moment, but it is really a or-or situation.
Or use the configuration file for the zones, or use the zone add/delete
command. Mixing them has always resulted in "situations", but with this
version this becomes more prominent.

We understand that some people rather use a file, that is also why the
option to do this is still there. And like you, we think that a tool
is needed that synchronizes the zone list. However there should be a
single flow, on how changes ready the ODS back-end. And with the
current set-up, that is not really the case.

I hope we have satisfied that you use-case will remain a use-case for
OpenDNSSEC, but with more consistent semantics.

\Berry

[Yuri Schaeffer]

Post by Berry A.W. van Halderen

Post by Casper Gielen
It's not a big deal, I could write a wrapper that takes a configuration
file and make the appropriate calls to ods-enforcer add/remove, but the
old system worked fine for me.

It is still possible at the moment, but it is really a or-or situation.
Or use the configuration file for the zones, or use the zone add/delete
command. Mixing them has always resulted in "situations", but with this
version this becomes more prominent.

More specifically you'll have the following commands available:

ods-enforcer zonelist export
ods-enforcer zonelist import


cmd> help zonelist import
Usage:
zonelist import
[--remove-missing-zones] aka -r
[--file <absolute path>] aka -f

Help:
Import zones from zonelist.xml into enforcer database.

Options:
remove-missing-zones Remove any zones from database not existed in
zonelist file
file File to import, instead of zonelist file configured in conf.xml

//Yuri