[Opendnssec-develop] Re: [OpenDNSSEC] #161: Patch: 2-phase key backup for ksmutil

[OpenDNSSEC]

#161: Patch: 2-phase key backup for ksmutil
------------------------+---------------------------------------------------
Reporter:  vanrein      |       Owner:  sion          
    Type:  enhancement  |      Status:  new           
Priority:  major        |   Component:  Enforcer      
 Version:               |    Keywords:  2-phase backup
------------------------+---------------------------------------------------

Comment(by vanrein):

 Hi,

 Jakob, you've mentioned bringing down the KASP Enforcer, so we tried it.
 The only thing it did was move the synchronisation problem out of
 OpenDNSSEC and into surrounding scripts.  This results in the opposite of
 our intention of simplifying the rolling out of DNSSEC.  Can you please
 explain why you think this need not go into OpenDNSSEC?  We only see
 evidence that we were right to ask for this months ago (details follow).
 Please note that you're the first one I ever hear talking about the
 precaution of stopping a database during its backup -- I've seen enough
 mature database solutions run by paranoid operators that happily do
 without.

 As for versioning and "new feature" status, it's interesting for us to not
 have to wait this long.  During a recent meeting we therefore agreed to
 make a simple patch to 1.1.1 and release it as a working version 1.1.2
 that would include a (possibly intermediary) version of this feature.
 Since we've been asking for it months ago already, and since we're the
 ones who experienced the problems arising from the stop-KASP-Enforcer
 approach, we thought we'd best submit a patch, making the inclusion of
 such functionality a breeze.   That's the patch submitted here.  We
 believe that it will be of value to all current users of OpenDNSSEC and
 that it is vital to the registrar-level (of which we are earlybird
 examples) which we should aim for as soon as possible, now that the root
 is signed.  If that implies using other numbering than 1.1.2 then we might
 have to consider that, or perhaps even bending the release rules.

 As for the details of what we experienced when stopping the KASP Enforcer:
 To the backup process, it is vitally important that the KASP Enforcer is
 not running.  To ensure that, other processes that may stop the KASP
 Enforcer (such as database backup, and even plain manual intervention)
 should never start it back up if a key backup is in progress.  What we did
 to achieve that, is to ensure that the KASP Enforcer cannot be taken down
 by more than one process at a time; we submitted a patch to /etc/init.d
 /ods-control to support that level of control and feedback.  The problem
 then became that other procedures would block, while waiting for the KASP
 Enforcer to come back online.  This is an inconvenience, and it is hard to
 distinguish from a crash of parts of the software.  Something else we've
 noticed is that the KASP Enforcer is not designed to handle quick
 stop/start sequences, and is therefore better kept running.  If not, the
 PID file and the actual PID start mismatching, so ods-control gets
 confused, and the KASP Enforcer does not terminate properly.  All this
 strengthened our desire to see this small piece of synchronisation put in
 the place where its need arises, namely during the backup commands.  It
 helps us to solve the problem we see, and may help others to avoid running
 into such problems by overlooking them.

 -Rick

-- 
Ticket URL: <http://trac.opendnssec.org/ticket/161#comment:2>
OpenDNSSEC <http://www.opendnssec.org/>
OpenDNSSEC