[Opendnssec-user] 1.4 to 2.1 migration

Paul Duffy via Opendnssec-user opendnssec-user at lists.opendnssec.org
Mon Jan 6 11:15:19 UTC 2020


Are there any plans to support mysql backend in the future? Currently working on a migration plan from 1.4 -> 2.1 (RHEL6 -> RHEL8 as well), we’ve always used compiled versions of OpenDNSSEC given the lack of builtin support for MySQL backend in rpm’s (EPEL etc.)

-Paul

-- 
Paul Duffy
Network Operations
IE Domain Registry CLG
Tel: +353 (1) 2365416
Fax: +353 (1) 2300365
Web: www.iedr.ie <http://www.iedr.ie/>



------------------------------------------------------------------------------------
Registered Office: Fourth Floor, Block 2, Harbour Square,
Dun Laoghaire, Co. Dublin. Registered in Ireland. No: 315315
------------------------------------------------------------------------------------
------------------------------------------------------------------------------------
The enclosed document is CONFIDENTIAL to addressee and
IE Domain Registry Ltd. The intended addressee is NOT
AUTHORISED to copy, distribute, disclose or otherwise use
the information disclosed. Please also note that this
information should not be edited or redistributed in any way.
------------------------------------------------------------------------------------




> On 5 Jan 2020, at 19:24, Paul Wouters via Opendnssec-user <opendnssec-user at lists.opendnssec.org> wrote:
> 
> [CAUTION: EXTERNAL EMAIL. This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.]
> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20200106/5b2a217d/attachment.htm>
-------------- next part --------------
_______________________________________________
Opendnssec-user mailing list
Opendnssec-user at lists.opendnssec.org
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user


More information about the Opendnssec-user mailing list