[Opendnssec-develop] from xml to DB

[John Dickinson]

Changes I made to the way I think things work today are. These are  
mostly me just catching up with the current state of the xml files,  
but there are one or two issues to resolve.

1. DB schema (http://www.opendnssec.se/browser/docs/DB.pdf) no longer  
needs to hold the zone adapter information. So the zone table is now  
just zone_id, zone_name, policy_id - and exists so that one can  
calculate the number of keys to generate.

2. DB schema - Adapters table is gone

3. If I understand things the signer engine will read the zone list to  
figure out which adapter to use and where the file is. BTW - I think  
we should just enforce a hard coded standardized file naming system  
rather than explicitly specify a path/name for every file.

Something like this (thanks Jakob)

# programs et al
PREFIX/{bin,lib,include}

# static configurations, not written to by the daemons (SYSCONFDIR is  
usually /etc). not writable by the daemons.
SYSCONFDIR/opendnssec/kasp.xml
SYSCONFDIR/opendnssec/conf.xml
SYSCONFDIR/opendnssec/zonelist.xml
SYSCONFDIR/opendnssec/kasp.rng
SYSCONFDIR/opendnssec/conf.rng
SYSCONFDIR/opendnssec/zonelist.rng

# dynamic stuff (LOCALSTATEDIR is usually /var). writable by daemons.
LOCALSTATEDIR/opendnssec/signconf/<zonename>.conf
LOCALSTATEDIR/opendnssec/unsigned/<zonename>
LOCALSTATEDIR/opendnssec/signed/<zonename>
LOCALSTATEDIR/opendnssec/kasp/kasp.`date`.xml (These are exported  
kasp.xml files for historical or audit reasons)

4. kaspimporter.pl now reads kasp.xml and zonelist.xml.

5. Applications all read config.xml directly.

6. Since the repository information is now in config.xml and that is  
read by all applications it doesn't need to be in the DB. So the  
security modules table could be dropped. However, the policies need to  
refer to the repository to use for ksk's or zsk's. As things stand we  
either add

a) a repository field to the policies table,
b) an integer ID to the config.xml or
c) have kaspimporter read the config.xml repository info into the  
securitymodules table in the DB (not the PIN).

I am not sure which I favour - I think c. Thoughts?

BTW - I really think that each repository needs to have a specified  
capacity, even if it is effectively constrained by the size of disk  
you can buy. This was/is in the DB and should be in config.xml

7. We need to think how changes to the xml files are reported to the  
various apps and the DB gets updated. We may, at some point develop a  
GUI that will access the KASP database directly removing the need for  
the KASP importer altogether. This GUI will also create the necessary  
entries in conf.xml and zonelist.xml - therefore this could be ignored  
for v1 I suppose.

8. HSMkey_ID field in the keypairs table now needs to hold a uuid.

9. The securitymodule_id field in the keypairs table is no longer  
needed if libhsm will search for a uuid in all HSMs. and the  
communicator only passes the uuid to the signer anyway.

OK thats enough for one email. I will start testing the modified  
kaspimporter.pl and get it checked in...

John

---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009