[Opendnssec-develop] from xml to DB
jad at jadickinson.co.UK
Mon Apr 20 14:15:53 UTC 2009
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
# static configurations, not written to by the daemons (SYSCONFDIR is
usually /etc). not writable by the daemons.
# dynamic stuff (LOCALSTATEDIR is usually /var). writable by daemons.
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
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...
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
More information about the Opendnssec-develop