[Opendnssec-user] 1.4 to 2.1 migration

[Paul Wouters via Opendnssec-user]

Hi,

I've created fedora31/rawhide RPMS as the first step in supporting
migration from 1.4 to 2.1. I did encounter a number of issues trying
to support this. Before I push this into rawhide, I would like to see
if anyone is able to test this for me. It is important that this testing
only be done on a COPY of your real 1.4 production system. Note that
this only supports sqlite, not mysql, as that is the method used for the
rpms shipped with fedora/RHEL that I need to support.

RPMS, including SRPM if you want to recompile this for rhel/centos 7/8:

https://nohats.ca/ftp/opendnssec/migration/


The issues encountered:

1) ods-migrate segfaulting

Not entirely sure when/how this occurs, probably with an xml file is not
as it expceted it to be?

2) no easy way to detect a kasp database has been migrated

To work around this, I modified sqlite_convert.sql and added:

-- For rpm based systems to see if db was migrated already. store opendnssec major minor version
CREATE TABLE rpm_migration (
         major INTEGER,
         minor INTEGER
);
INSERT INTO rpm_migration VALUES(2, 1);

Then the rpm %post phase can check for this to see if it still needs to
migrate the kasp database or not. It would be nice if upstream adopts
something similar to this approach.

3) the migration scripts called other scripts without paths.

I change the paths during build now, but its pretty hacky. Perhaps
attempt to not write various split sql files and merge it all into one.
(example: find_problematic_zones.sql, but also the SCHEMA= variables)

4) find_problematic_zones issue ?

I'm not sure why just migrating the database would lead to issues. It
should just copy whatever real state is there? For me, this caused
issues because I had a few zones waiting on ds-seen. Why can't they not
be in the new databse in the same waiting on ds-seen state? Aborting
the migration is the worst thing to do, as I cannot have the new rpm
installed and the database reverted to the old one.

5) <Interval> barfing

It would be REALLY useful to just ignore it and not blow up on this.
Again, this creates a big problem as I now have to hack up the
existing configuration files and automatic downgrading on failure
becomes basically impossible. Why not just ignore it :(

6) confusing about location enforcer socket?

I have some re-start issues due to changes socket locations it seems.
On a note, enforcer's socket is called enforcer.sock but ods-signer's
sock is not called signer.sock but engine.sock ? Not sure why :P

7) ods-ksmutil is gone

It took me a bit to figure out this is now done by ods-enforcer. A stub
man page or alias or something would have been nice.


I tested this migration on a copy of my production server. That server has the
additional problem that 1.4 software errors are causing it to generate
1 new key per enforcer interval, something that has been going on likely
for years, and throwing an error:

Jan  5 12:50:16 ns0 ods-enforcerd: Not enough keys to satisfy zsk policy for zone: chaishinyu.com. keys_to_allocate(1) = keys_needed(1) - (keys_available(1) - keys_pending_retirement(1))
Jan  5 12:50:16 ns0 ods-enforcerd: Tried to allocate 1 keys, failed on allocating key number 1
Jan  5 12:50:16 ns0 ods-enforcerd: ods-enforcerd will create some more keys on its next run

As a result, my install has thousands or millions of keys and just listing
these from softhsm on my laptop took more then 30 minutes, when I had
to kill it because I ran out of battery.  I wish there was a method to
export only the "known" keys to opendnssec and start a fresh new softhsm
with just those. That could then also be used as part of the migration
in case other 1.4.x installs have suffered the same bitrot as mine.

Paul
_______________________________________________
Opendnssec-user mailing list
Opendnssec-user at lists.opendnssec.org
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user