[Opendnssec-user] Questions about 'merging' two sqlite kaspdb files into one mysql database

[Siôn Lloyd]

On 26/11/15 08:30, Anne van Bemmelen wrote:
> Dear listmembers,
> 
> I am investigating the following scenario, in which I try to ‘merge’ two
> kaspdb files.
> 
>  
> 
> Current situation:
> 
> In the current situation there are two signing systems: signera and signerb.
> 
> RedHat5, ODS 1.3.x, SQLite backend.
> 
> signera signs zone1 and zone2.
> 
> signerb signs zone3 and zone4.
> 
> Both signers use the policy ‘default’, but they differ in some details.
> 
>  
> 
> New situation:
> 
> One signer system: signerc.
> 
> Ubuntu 14.04, ODS 1.4.7, MySQL backend.
> 
> Signerc needs to sign all zones: zone[1234].
> 
> Two defined policies: ‘default’ and ‘mypolicy’.
> 
> On a new HSM all involved keys are restored, with known CKA_id’s.
> 
>  
> 
> The usual migrate scripts (ODS 1.3 to 1.4, sqlite to mysql) won’t work
> in this case, because two kaspdb’s are involved.
> 
>  
> 
> I did the following:
> 
> Configure conf.xml, kasp.xml and zonelist.xml in the appropriate way,
> with one repository, two policies, four zones, each with the desired policy.
> 
> Ods-ksmutil setup.
> 
> For each zone import all keys with: ods-ksmutil key import [all options]
> 
> Most options are obvious from ods-ksmutil key list –v –zone <zoneN>.
> 
> I checked the values for –time and –retire in the existing sqlite tables
> keypairs (field ‘generate’) and ‘dnsseckeys’ (field ‘retire’).
> 
>  
> 
> This results in:
> 
> ods-ksmutil key list –v shows the same output on old and new signer.
> 
> After ‘ods-control start’  all  zones are signed as expected, everything
> seems to work (besides key rollovers that I didn’t test yet).
> 
>  
> 
> *These are the differences between the contents of sqlite and mysql
> databases:
> 
> In the mysql database I find the following :
> 
> table policies: initially the field salt has value NULL, after ODS has
> started, it gets a new value.
> 
> table policies: the field salt_stamp contains date/time of import
> (sqlite contains the real salt generation time, equal to dnskeys active
> time).
> 
>  
> 
> table keypairs: I expected the field ‘generate’ to contain the –time
> value, specified during the key import, but this value is NULL.
> 
> Instead this date is filled in the table dnsseckeys, field ‘active’. Is
> this normal behaviour?
> 
>  
> 
> table dnsseckeys: the fields ‘publish’ and ‘ready’ have the NULL value
> (in sqlite the real timestamp).
> 
> table keypairs: the field ‘fixedDate’ has value 1 (in sqlite value 0).
> Freshly created keys appear to have have fixedDate value 0.
> 
>  

Interesting problem, it is not one I'd thought about before.

note that import keys was intended as a way of moving keys into ODS from
some other signing solution. It imports only what is required to get the
key into the correct state and not the history of that key or any other
parameters that were in use against the zone.

> 
> In my opinion the following additional actions are necessary:
> 
> -          Manually update salt with the value in sqlite
> 
> -          Manually update salt_stamp with the value in sqlite
> 
> -          salt_stamp and active date have to be the same, during import
> use the active date with the –time option 

Salt will not be imported with keys - it is the salt for the NSEC3
chain. Like you say, if you want the salt to remain (and not be changed
until it would have been under the old system) then you will need to
import these parameters. Is there a specific reason that you do not want
the salt to change?

> 
>  
> 
> I think there’s no need to fill in the dnssec fields ‘generate’,
> ‘publish’ and ‘ready’.

No, these are part of the keys history and the assumption was that this
data would not be available for keys being imported.


> 
> Is my interpretation correct? Is there anything else I have overlooked?
> 
> Also, I don’t understand the meaning of the fixedDate field, should I
> change it back to 0?
> 

This flag means that even if you change the policy to allow keys to be
used for longer, the retire time of _this_ key will not change to
reflect that. This flag is set when you import a key with a retire time
as you are telling the system when you want this key to retire.


Sion

>  
> 
> All comments and suggestions are welcome.
> 
> Thanks in advance,
> 
>  
> 
> Anne van Bemmelen
> 
> SIDN | Meander 501| 6825 MD | Postbus 5022 |  6802 AE | ARNHEM T +31
> (0)26 352 55 00  | M +31 (0)6 15 06 33 96 | F +31 (0)26 352 55 05
> anne.vanbemmelen at sidn.nl| <mailto:anne.vanbemmelen at sidn.nl|>
> www.sidn.nl| <http://www.sidn.nl|> Key-ID: 0xB8A5F0B2
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> Opendnssec-user mailing list
> Opendnssec-user at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
>