Discussion:
[Opendnssec-user] OpenDNSSEC 2.1.0 released
Yuri Schaeffer
2017-02-22 09:53:07 UTC
Permalink
Dear Community,

No issues with the RC1 have come up in the last 1.5 weeks so hereby we
announce the OpenDNSSEC 2.1.0 release.

OpenDNSSEC 2.1 development was focused on improving the daemon code for
the Signer and Enforcer. As such it is much more a steady incremental
improvement rather than revolutionary. With this style of development we
hope that a migration from 1.4, for which an end-of-life is to be given,
is facilitated.

Many of these changes are not directly visible but improve the handling
and responsiveness or unify the Signer and Enforcer code bases. These
improvements are not all mentioned in the issue list below because of
their detail. Attention has been given to different roll-over methods
and we now test fully with SoftHSMv2.

MIGRATION

There are no migration steps needed from 2.0.x to 2.1.0. Version 1.4.10
can be migrated directly to 2.1.0 (see MIGRATION text file in tarball).
Any version prior to 1.4.10 should upgrade to 1.4.10 first.

FEATURES

* OPENDNSSEC-779: The Enforcer will now have an 'enforce' and
'signconf' task scheduled per zone. 'Resalt' tasks are scheduled per
policy. This improves performance and parallelism since no longer all
zones need to be evaluated for work to be done. Further parallelism
improvements in the Enforcer are on our roadmap.
* OPENDNSSEC-681: When daemonizing the Signer and Enforcer daemons fork
to the background. Since they are then no longer able to print
messages to the console start up problems are harder to debug. Now,
after the fork() call the parent process will wait for the daemon to
signal successful start and will print relevant error messages in
case it doesn't.
* OPENDNSSEC-479: On sending notifies and initiating zone transfers the
signer will now use the first interface mentioned in the listener
section of conf.xml. This way the interface selection is not left to
the OS, which could cause outgoing packets have an unexpected source
address if multiple interfaces have a route to the destination
address.
* OPENDNSSEC-759: The Signer doesn't need to access the HSM for every
zone during start up any more. This is done later by the worker
threads. This way the signer starts quicker and is earlier available
for user input.
* OPENDNSSEC-450: Implement support for ECDSA P-256, P-384 and GOST.
To be able to use this your HSM should have support as well.
SoftHSMv2 can be compiled with support for these.
* OPENDNSSEC-503: When adding a new zone to OpenDNSSEC the Enforcer is
a little less conservative and will add signatures and keys to the
zone in one go. Thereby mimicking OpenDNSSEC 1.4. Effectively new
zones are earlier fully signed by the TTL of the DNSKEY set.
* A bash autocompletion script is included in contrib for ods-enforcer
and ods-signer. Commands, parameters, zone names and key identifiers
can be autocompleted from the command line.

FURTHER IMPROVEMENTS

* OPENDNSSEC-530: The <Interval> tag for the Enforcer in conf.xml has
been unused and deprecated in 2.0. since 2.1 this tag is no longer
allowed to be specified.
* Show help for ods-enforcer-db-setup with -h or --help
* OPENDNSSEC-836: If the listening port for Signer is not set in
conf.xml file, the default value "15354" is used.
* OPENDNSSEC-864: ods-signer didn't print help. Also --version and
--socket options where not processed.
* OPENDNSSEC-858: OpenDNSSEC 2.0 did print "completed in x seconds" to
stderr for enforcer commands. This line is removed.
* SUPPORT-208: Running 'ods-enforcer key export' included a comment
string with key properties. This is dropped to aid parsing.
* OPENDNSSEC-552: By default 'ods-enforcer key export --ds' included
the SHA1 version of the DS. SHA1 use is discouraged in favour of
SHA256. To get the SHA1 DS use the --sha1 flag. This flag is
immediately deprecated and will be removed from future versions of
OpenDNSSEC.
* OPENDNSSEC-465: ods-kaspcheck warns about algorithm mismatch between
keys.
* When a zone is deleted the Enforcer now properly removes all tasks
associated with that zone from its task queue.
* In the key section of the kasp.xml file, the algorithm length is no
longer optional. For ECDSA and GHOST keys this value is ignored.
* The Enforcer and the Signer now have a HSM key cache shared between
their threads so no longer every thread needs to iterate over all
keys, which can potentially be very slow for some HSMs.
* OPENDNSSEC-721: Our integration testing environment now uses
SoftHSMv2 instead of version one.
* OPENDNSSEC-844: warning when lifetime of key is smaller than
signature validity time.
* OPENDNSSEC-311: Installation can now set the right permissions on
used files for a configurable user/group when not running OpenDNSSEC
as root.
* OPENDNSSEC-593: More gracefully cope when zone configured for signer
but signconf not yet available.
* OPENDNSSEC-600: Log critical error if key is not inserted due to
policy parameters misconfiguration.
* OPENDNSSEC-694: Domain Names in the value/answer part of records
(e.g. named referred to by PTR records) where mapped to lowercase.
* OPENDNSSEC-803 : Extensive logging on aborting the application.

BUGS FIXED

* OPENDNSSEC-778: Double NSEC3PARAM record after resalt.
* SUPPORT-29: signer clear <zone> would assert when signconf wasn't
read yet.
* OPENDNSSEC-869: ds-seen command did not give error on badly formatted
keytag.
* OPENDNSSEC-849: Crash on free of part of IXFR structure.
* OPENDNSSEC-601: signer and enforcer working dir would not properly
fallback to default when not specified.
* OPENDNSSEC-689: Failure of daemon during start up is not logged.
* OPENDNSSEC-850: Date of new transition could temporarily be incorrect.
* OPENDNSSEC-851: Change in verbosity level not immediately propagated.
* Various memory leaks, resolving compiler warnings, and static code
analysis.
* Libxml2 clean up improvements (Thanks he32).

Download:
* https://dist.opendnssec.org/source/opendnssec-2.1.0.tar.gz
* https://dist.opendnssec.org/source/opendnssec-2.1.0.tar.gz.sig
* Checksum SHA256:
0ec6094fd4cded58bcff872b251f1b004876b67c6650c38a4875018a18e38545

Kind regards,
The OpenDNSSEC team
Fred.Zwarts
2017-03-02 10:27:39 UTC
Permalink
Post by Yuri Schaeffer
Dear Community,
No issues with the RC1 have come up in the last 1.5 weeks so hereby we
announce the OpenDNSSEC 2.1.0 release.
...
Due to holidays I could not try this new version earlier on our test system.
Today I tried to build it, but it failed.

As usual, I use ./configure without parameters. It gives one warning:
configure: WARNING: doxygen not found - will not generate any doxygen
documentation
But I think this is not important for us. We use the documentation on the
web.

Then the make failed.
First there was a warning:
scheduler/task.c: In function ‘task_perform’:
scheduler/task.c:136:9: warning: implicit declaration of function ‘clamp’
[-Wimplicit-function-declaration]
task->backoff = clamp(task->backoff * 2, 60, ODS_SE_MAX_BACKOFF);
^

I don't know how serious this warning is.

Then there was a fatal error:
janitor.c:54:23: fatal error: libunwind.h: No such file or directory
#include <libunwind.h>
^
compilation terminated.

Does it mean that we have to install additional packages? If yes, which
ones?

I tried to build it on a SLES system:
SUSE Linux Enterprise Server 12 (x86_64)
VERSION = 12
PATCHLEVEL = 2
Yuri Schaeffer
2017-03-02 11:04:14 UTC
Permalink
Hi Fred,
Post by Fred.Zwarts
Then the make failed.
scheduler/task.c:136:9: warning: implicit declaration of function
‘clamp’ [-Wimplicit-function-declaration]
task->backoff = clamp(task->backoff * 2, 60, ODS_SE_MAX_BACKOFF);
^
I don't know how serious this warning is.
This should not be a deal breaker. But thanks for reporting, we will fix it.
Post by Fred.Zwarts
janitor.c:54:23: fatal error: libunwind.h: No such file or directory
#include <libunwind.h>
^
compilation terminated.
Does it mean that we have to install additional packages? If yes, which
ones?
Hmm strange, not having libunwind should be caught by configure.
Can you run:

sh autogen.sh

and then configure again. Does that help?

//Yuri
Jerry Lundström
2017-03-02 14:37:27 UTC
Permalink
Post by Yuri Schaeffer
Hmm strange, not having libunwind should be caught by configure.
configure.ac is only checking for the lib, not the headers.
Post by Yuri Schaeffer
AC_CHECK_LIB(unwind, unw_backtrace, [AC_DEFINE([HAVE_LIBUNWIND],
[1], [Define if libunwind supported]) LIBS="$LIBS -lunwind
-lunwind-x86_64"])
Cheers,
Jerry
Wytze van der Raay
2017-03-02 11:09:16 UTC
Permalink
Hi Fred,
Post by Fred.Zwarts
...
janitor.c:54:23: fatal error: libunwind.h: No such file or directory
#include <libunwind.h>
^
compilation terminated.
Does it mean that we have to install additional packages? If yes, which ones?
SUSE Linux Enterprise Server 12 (x86_64)
VERSION = 12
PATCHLEVEL = 2
You need to run "zypper install libunwind-devel" on SUSE systems.

Regards,
Wytze van der Raay
Berry A.W. van Halderen
2017-03-02 11:31:57 UTC
Permalink
Post by Yuri Schaeffer
Hi Fred,
Post by Fred.Zwarts
...
janitor.c:54:23: fatal error: libunwind.h: No such file or directory
#include <libunwind.h>
Thanks for reporting it. Unwind is not necessary, for some reason
the configure script has detected the availability of it, but then
failed to use it, or some detection bug from our side. I've not
included SuSE on our test platforms, the other platforms do not
have this problem shown.
Hopefully we can track it down later such that it indeed is optional,
as it should be.

\Berry
Fred.Zwarts
2017-03-02 11:55:20 UTC
Permalink
Post by Yuri Schaeffer
Hi Fred,
Post by Fred.Zwarts
...
janitor.c:54:23: fatal error: libunwind.h: No such file or directory
#include <libunwind.h>
^
compilation terminated.
Does it mean that we have to install additional packages? If yes, which ones?
SUSE Linux Enterprise Server 12 (x86_64)
VERSION = 12
PATCHLEVEL = 2
You need to run "zypper install libunwind-devel" on SUSE systems.
Regards,
Wytze van der Raay
Thanks. After the installation of the "libunwind-devel" package "make" ran
without further problems.
Sebastian Wiesinger
2017-04-20 12:02:43 UTC
Permalink
Post by Yuri Schaeffer
Dear Community,
No issues with the RC1 have come up in the last 1.5 weeks so hereby we
announce the OpenDNSSEC 2.1.0 release.
OpenDNSSEC 2.1 development was focused on improving the daemon code for
the Signer and Enforcer. As such it is much more a steady incremental
improvement rather than revolutionary. With this style of development we
hope that a migration from 1.4, for which an end-of-life is to be given,
is facilitated.
Hello,

I tested the migration today but ran into errors with the MySQL
Migration script. I had these before with 1.4 -> 2.0 but they are
still there for me:


Converting database
ERROR 1064 (42000) at line 663: You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the
right syntax to use near '--Set to OMN if Tactive + Dttl < Tnow
UPDATE keyState
SET state = 2
WHERE keySta' at line 1

When I comment out this part I get other errors. This is with the
standard Debian Jessie MySQL version 5.5.54-0+deb8u1.

Is there someting I'm missing? Has anyone successfully converted their
MySQL database to 2.1 on a Debian system?

Regards

Sebastian
--
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
Yuri Schaeffer
2017-04-20 12:36:54 UTC
Permalink
Hi Sebastian,
Post by Sebastian Wiesinger
Converting database
ERROR 1064 (42000) at line 663: You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the
right syntax to use near '--Set to OMN if Tactive + Dttl < Tnow
UPDATE keyState
SET state = 2
WHERE keySta' at line 1
Can you try the below patch? (also attached in case it gets messed up by
the mail formatting)

Depending on the version MySQL is somewhat picky on how comments are
written. It should be "-- " instead of "--".

//Yuri


diff --git a/enforcer/utils/1.4-2.0_db_convert/mysql_convert.sql
b/enforcer/utils/1.4-2.0_db_convert/mysql_convert.sql
index 8a985497c..de16058fa 100644
--- a/enforcer/utils/1.4-2.0_db_convert/mysql_convert.sql
+++ b/enforcer/utils/1.4-2.0_db_convert/mysql_convert.sql
@@ -660,7 +660,7 @@ JOIN REMOTE.dnsseckeys
JOIN mapping
ON mapping.state = REMOTE.dnsseckeys.state;

---Set to OMN if Tactive + Dttl < Tnow
+-- Set to OMN if Tactive + Dttl < Tnow
UPDATE keyState
SET state = 2
WHERE keyState.state = 1 AND keyState.type = 1 AND keyState.id IN (
@@ -676,8 +676,8 @@ WHERE keyState.state = 1 AND keyState.type = 1 AND
keyState.id IN (
ON policy.id = zone.policyId
WHERE CAST(UNIX_TIMESTAMP(REMOTE.dnsseckeys.active) +
policy.signaturesValidityDefault as INTEGER) < UNIX_TIMESTAMP(now()));

---Force the RRSIG state in omnipresent if rumoured and there is no old ZSK
---unretentive
+-- Force the RRSIG state in omnipresent if rumoured and there is no old ZSK
+-- unretentive
UPDATE keyState
SET state = 2
WHERE keyState.id IN (
Sebastian Wiesinger
2017-04-20 13:42:06 UTC
Permalink
Post by Yuri Schaeffer
Hi Sebastian,
Post by Sebastian Wiesinger
Converting database
ERROR 1064 (42000) at line 663: You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the
right syntax to use near '--Set to OMN if Tactive + Dttl < Tnow
UPDATE keyState
SET state = 2
WHERE keySta' at line 1
Can you try the below patch? (also attached in case it gets messed up by
the mail formatting)
Depending on the version MySQL is somewhat picky on how comments are
written. It should be "-- " instead of "--".
That worked but it failed later on:

Creating database opendnssec20 (as user opendnssec)
Creating tables in opendnssec20 (as user opendnssec)
Converting database
ERROR 1064 (42000) at line 664: You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the
right syntax to use near 'INTEGER) < UNIX_TIMESTAMP(now()))' at line
14

When I comment that part out I get:

Creating database opendnssec20 (as user opendnssec)
Creating tables in opendnssec20 (as user opendnssec)
Converting database
ERROR 1064 (42000) at line 681: You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the
right syntax to use near '== rs.keyDataId
WHERE rs.type == 1 AND dk.type == 2 AND rs.state == 1 AND dk.sta' at
line 5


And on to the next error:

Creating database opendnssec20 (as user opendnssec)
Creating tables in opendnssec20 (as user opendnssec)
Converting database
ERROR 1064 (42000) at line 697: You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the
right syntax to use near '== keyData.id
JOIN keyState AS KS2
ON KS2.keyDataId == keyData.id
JOIN (
SELE' at line 5


So... yeah

Regards

Sebastian
--
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
Yuri Schaeffer
2017-04-20 14:08:13 UTC
Permalink
Post by Sebastian Wiesinger
So... yeah
Ah! I was wondering why it felt like I fixed those issues already. Here
they are:
https://github.com/opendnssec/opendnssec/pull/661

They're still in a pull request and not released yet.

//Yuri
Eliot Lear
2017-04-20 15:53:28 UTC
Permalink
Hi Juri,

Given this, can those of us on 1.4 expect a 2.1.1 release?

Eliot
Post by Yuri Schaeffer
Post by Sebastian Wiesinger
So... yeah
Ah! I was wondering why it felt like I fixed those issues already. Here
https://github.com/opendnssec/opendnssec/pull/661
They're still in a pull request and not released yet.
//Yuri
_______________________________________________
Opendnssec-user mailing list
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
Yuri Schaeffer
2017-04-21 08:26:40 UTC
Permalink
Post by Eliot Lear
Given this, can those of us on 1.4 expect a 2.1.1 release?
Yes. A patch release next week seems reasonable after we discuss it in
our team.

//Yuri
Yuri Schaeffer
2017-04-28 12:46:55 UTC
Permalink
Post by Eliot Lear
Given this, can those of us on 1.4 expect a 2.1.1 release?
As of today we made a release of 2.1.1.
For those who are still living in the past, when there was only one true
way of rolling your keys, and changing polices would botch your
database, we also made a shiny new 1.4.14 release.
https://www.opendnssec.org. Enjoy!

//Yuri
Volker Janzen
2017-04-28 12:58:30 UTC
Permalink
Hi Yuri,

I followed the discussion on the upgrade path of some users. Today I had
a look at my OpenDNSSEC version. It's 1.4.6 because it's the Debian
jessie package. When I look at the upcoming stretch release, there will
be 2.0.4. Are there any binary packages available for running the 2.1.x
versions on Debian/Ubuntu?

I now see an issue on the path how to update and maintain a current
OpenDNSSEC version.

Any suggestions? Am I required to compile OpenDNSSEC myself? I made some
bad experiences with self-compiling when I started using OpenDNSSEC.


Kind regards,
Volker
Post by Yuri Schaeffer
Post by Eliot Lear
Given this, can those of us on 1.4 expect a 2.1.1 release?
As of today we made a release of 2.1.1.
For those who are still living in the past, when there was only one true
way of rolling your keys, and changing polices would botch your
database, we also made a shiny new 1.4.14 release.
https://www.opendnssec.org. Enjoy!
//Yuri
_______________________________________________
Opendnssec-user mailing list
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
Yuri Schaeffer
2017-04-28 13:33:45 UTC
Permalink
Hi Volker,
Post by Volker Janzen
I followed the discussion on the upgrade path of some users. Today I had
a look at my OpenDNSSEC version. It's 1.4.6 because it's the Debian
jessie package. When I look at the upcoming stretch release, there will
be 2.0.4.
When I look at my package manager (apt, Debian unstable) both 1.4.6 and
2.0.4 are available. So likely you can continue to use 1.4.6.
(though that doesn't reflect on the packages.debian.org website, I'm not
sure how that works)
Post by Volker Janzen
Are there any binary packages available for running the 2.1.x
versions on Debian/Ubuntu?
We do not provide such a thing. Ondřej SurÃœ [1] packages OpenDNSSEC for
Debian, maybe he's able to help you there.

[1] https://qa.debian.org/developer.php?login=ondrej%40debian.org
Post by Volker Janzen
I now see an issue on the path how to update and maintain a current
OpenDNSSEC version.
Any suggestions? Am I required to compile OpenDNSSEC myself? I made some
bad experiences with self-compiling when I started using OpenDNSSEC.
Well, if you end up with a 2.X any other than 2.1.1 and find yourself
required to go over the migration steps I strongly recommend you to use
the migration scripts from 2.1.1. So use the files from this directory
instead:
https://github.com/opendnssec/opendnssec/tree/2.1/develop/enforcer/utils/1.4-2.0_db_convert

//Yuri

Sebastian Wiesinger
2017-04-21 07:33:47 UTC
Permalink
Post by Yuri Schaeffer
Post by Sebastian Wiesinger
So... yeah
Ah! I was wondering why it felt like I fixed those issues already. Here
https://github.com/opendnssec/opendnssec/pull/661
They're still in a pull request and not released yet.
Thank you for that, I'll test it.

So noone really tested migrating a MySQL backed OpenDNSSEC
installation from 1.4 to 2.x? I'm a bit concerned about this, as there
are a lot of TLDs using OpenDNSSEC. Do they all still use 1.4? Do they
not use MySQL? Didn't anyone test this in development?

Regards

Sebastian
--
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
Yuri Schaeffer
2017-04-21 08:05:34 UTC
Permalink
Post by Sebastian Wiesinger
So noone really tested migrating a MySQL backed OpenDNSSEC
installation from 1.4 to 2.x? I'm a bit concerned about this, as there
are a lot of TLDs using OpenDNSSEC. Do they all still use 1.4? Do they
not use MySQL? Didn't anyone test this in development?
Well, I did test it. But it is a complex migration because the database
layout and key state representation changed radically. Unfortunately I
can only test a subset of every imaginable situation in my lifetime.

It is true (my impression) that most people run OpenDNSSEC with SQLite
and the migration script was initially developed (and mostly tested for
corner cases and such) for SQLite and later adapted for MySQL. Same
database layout, slightly different SQL dialect.
In that process there was an oversight of some SQL dialect issues, like
the comment syntax. But depending on your MySQL version /and/ the
contents of your database this may or may not be a problem. It wasn't
for me at the time and went undetected.

//Yuri
Sebastian Wiesinger
2017-04-21 08:12:26 UTC
Permalink
Post by Yuri Schaeffer
Post by Sebastian Wiesinger
So noone really tested migrating a MySQL backed OpenDNSSEC
installation from 1.4 to 2.x? I'm a bit concerned about this, as there
are a lot of TLDs using OpenDNSSEC. Do they all still use 1.4? Do they
not use MySQL? Didn't anyone test this in development?
Well, I did test it. But it is a complex migration because the database
layout and key state representation changed radically. Unfortunately I
can only test a subset of every imaginable situation in my lifetime.
Yes, I know that, I was just under the impression that someone might
have brought that up before. I didn't want to imply you had to test it
all yourself.
Post by Yuri Schaeffer
It is true (my impression) that most people run OpenDNSSEC with SQLite
and the migration script was initially developed (and mostly tested for
corner cases and such) for SQLite and later adapted for MySQL. Same
database layout, slightly different SQL dialect.
Okay, I was thinking that bigger installations would most likely
prefer MySQL but then again a TLD proably doesn't have a "big
installation" in regards to zones in the database...
Post by Yuri Schaeffer
In that process there was an oversight of some SQL dialect issues, like
the comment syntax. But depending on your MySQL version /and/ the
contents of your database this may or may not be a problem. It wasn't
for me at the time and went undetected.
That explains it, I thought it didn't work for MySQL at all from the
beginning. I can confirm that your patch does indeed fix it for me,
thank you. :)

Regards

Sebastian
--
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
Yuri Schaeffer
2017-04-21 08:24:27 UTC
Permalink
Post by Sebastian Wiesinger
I can confirm that your patch does indeed fix it for me,
Thank you.

//Yuri
Mathieu Arnold
2017-04-21 14:58:01 UTC
Permalink
Post by Yuri Schaeffer
Post by Sebastian Wiesinger
So noone really tested migrating a MySQL backed OpenDNSSEC
installation from 1.4 to 2.x? I'm a bit concerned about this, as there
are a lot of TLDs using OpenDNSSEC. Do they all still use 1.4? Do they
not use MySQL? Didn't anyone test this in development?
Well, I did test it. But it is a complex migration because the database
layout and key state representation changed radically. Unfortunately I
can only test a subset of every imaginable situation in my lifetime.
It is true (my impression) that most people run OpenDNSSEC with SQLite
Well, I don't know about most people, but I run OpenDNSSEC with (as of
right now) 2350 zones, and 5280 keys (with rollovers going on and all).

The SQLite backend was nice to begin with, but it is not workable for
large zone numbers.

I have not yet migrated from 1.4 because, well, ENOTIME, but it was on
my TODO for before the summer, I'd rather be sure quite it is going to
work :-)
Post by Yuri Schaeffer
and the migration script was initially developed (and mostly tested for
corner cases and such) for SQLite and later adapted for MySQL. Same
database layout, slightly different SQL dialect.
In that process there was an oversight of some SQL dialect issues, like
the comment syntax. But depending on your MySQL version /and/ the
contents of your database this may or may not be a problem. It wasn't
for me at the time and went undetected.
//Yuri
_______________________________________________
Opendnssec-user mailing list
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
--
Mathieu Arnold
Casper Gielen
2017-04-21 08:10:27 UTC
Permalink
Post by Sebastian Wiesinger
Post by Yuri Schaeffer
Post by Sebastian Wiesinger
So... yeah
Ah! I was wondering why it felt like I fixed those issues already. Here
https://github.com/opendnssec/opendnssec/pull/661
They're still in a pull request and not released yet.
Thank you for that, I'll test it.
So noone really tested migrating a MySQL backed OpenDNSSEC
installation from 1.4 to 2.x? I'm a bit concerned about this, as there
are a lot of TLDs using OpenDNSSEC. Do they all still use 1.4? Do they
not use MySQL? Didn't anyone test this in development?
FYI, I did migrate an installation using mysql from 1.4 to 2.0 using the
packages provided by Debian. It required a bit of fiddling to get the
database converted. The heavy work was done by
https://github.com/opendnssec/opendnssec/tree/develop/enforcer/utils/1.4-2.0_db_convert
but it took me a while to discover those instructions.
--
Casper Gielen <***@uvt.nl> | LIS UNIX
PGP fingerprint = 16BD 2C9F 8156 C242 F981 63B8 2214 083C F80E 4AF7

Universiteit van Tilburg | Postbus 90153, 5000 LE
Warandelaan 2 | Telefoon 013 466 4100 | G 236 | http://www.uvt.nl
Loading...