<div dir="ltr">Since I had to provide database and configuration files most of the correspondence went offlist, so here is an update and additional issue I got into.<div><br><div>One of the issues that made the migration fail was that I'm using shared keys ( <ShareKeys/> ) for one of my policies and the migration script did not cope well with it. Since then I was provided with updated version which worked well.</div><div><br></div><div>Another issue was that took us some time to figure out was that I did not pay attention the configure options when building ODS with mysql support changed, from --with-database-backend=mysql to  --with-enforcer-database=mysql. I was using the former when building 2.1.0 and as a result the enforcer was failing to connect to the DB.</div><div><br></div><div>The issue I now got into after switching to 2.1.0 is that the signconf xml files for zones which use NSEC3 state that NSEC is in use.</div><div><br></div><div>Originally it was:</div><div><div>                <Denial></div><div>                        <NSEC3></div><div>                                <OptOut /></div><div>                                <Hash></div><div>                                        <Algorithm>1</Algorithm></div><div>                                        <Iterations>10</Iterations></div><div>                                        <Salt>2807e01b1cb8b6d1</Salt></div><div>                                </Hash></div><div>                        </NSEC3></div><div>                </Denial></div></div><div><br></div><div>Now it is:</div><div>     <Denial><br></div><div>      <NSEC/></div><div>    </Denial></div><div><br></div><div>The zonefiles are still signed with NSEC3 though. Till now the signer daemon was using the signconf files to find how to sign a zone, but it seems this has changed now. For me it's bad because I use the data from the signconf files for the post-signing checks. Do you consider this a bug and is it possible to fix it? Thank you.</div><div><br></div><div>Emil</div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 28, 2017 at 4:33 PM, Berry A.W. van Halderen <span dir="ltr"><<a href="mailto:berry@nlnetlabs.nl" target="_blank">berry@nlnetlabs.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/28/2017 02:48 PM, Emil Natan wrote:<br>
> Testing migration from 1.4.13 to 2.0.4, convert_mysql fails with:<br>
><br>
> Creating database TEST1 (as user kaspuser)<br>
> Creating tables in TEST1 (as user kaspuser)<br>
> Converting database<br>
> ERROR 1062 (23000) at line 474: Duplicate entry '81' for key 'PRIMARY'<br>
><br>
> other than that no problems with the DB running 1.4.13.<br>
><br>
> I can provide the DB offlist if needed.<br>
> Thank you in advance.<br>
<br>
</span>Thanks for bringing this, yes please provide the original database<br>
state if possible as a full dump (mysql --opt) as I'd also like to look<br>
at the current schema.<br>
<br>
Although this isn't causing the problem as far as I can tell now, please<br>
also use version 2.1.0 for upgrading.  It contains important<br>
improvements as 2.0.4 is the last release of that branch and support<br>
is provided on the 2.1 branch.<br>
<br>
The error you get is puzzling, as it concerns just the transfer of one<br>
unique/primary key to another which shouldn't lead to duplicate entries.<br>
<br>
With kind regards,<br>
Berry van Halderen<br>
<br>
</blockquote></div><br></div>