[Opendnssec-user] ods-hsmutil

[elsif]

ODS-1.4.0-0.a2 + AEP Keyper

wiki.opendnssec.org states:
"The ods-hsmutil utility is designed to interact directly with your HSM 
and can be used to manually list, create or delete keys. It can also be 
used to perform a set of basics HSM tests."

--

I've created 5 KSK's and 31 ZSK's that are sitting on a Keyper.

I backup all relevant directories.

"ods-hsmutil list" shows the keys immediately after creation.

I start "enforcerd" so that keys are selected by ODS, and this seems to 
populate kasp.db's "keypairs" table.

I see these selected keys in "ods-ksmutil key list --verbose".

If I use sqlite3 to view kasp.db, I see all of my keys with a numeric ID 
as the first field.  It seems to use this for ordering in it's next key 
selection process.

Are these understandings correct?

--

Now...on this same setup, I kill enforcer and run "ods-ksmutil setup".

I do this because I want it to wipe the kasp.db.

I use sqlite3 to view kasp.db, and indeed dnsseckeys and keypairs are 
empty.

I run "ods-hsmutil list" again, and my 36 keys are there as expected.

I run "ods-ksmutil key list --verbose" and get back no keys, as expected.

I start enforcerd, believing that it will grab the list of keys from the 
HSM, and may or may not put them in the same order, but ordering is 
unimportant this time.

I run "ods-hsmutil list" again, and now there are 38 keys, 2 have been 
created.

I run "ods-ksmutil key list --verbose" and see that enforcer has selected 
the 2 new keys.

I didn't expect new keys to be created here.  I expected ODS to use the 
keys that already existed on the HSM.

Confused, I restore the ODS config I backed up at the beginning of this 
process.

I run "ods-hsmutil list" again and see 36 keys.

Where are the two keys that I just mistakenly created?

If "ods-hsmutil list" isn't connecting to the HSM and getting it's list of 
keys every time I run it...where is it getting it's information?

I know this isn't a conventional bug report or technical problem, and I 
apologize for that.

Clearly there's a bad assumption on my part somewhere in here.

Thanks,

-jake