[Opendnssec-develop] ksmutil

[Rickard Bondesson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> Some general observations: 
> 
> a) Would "ksm" be better than "ksmutil" (shorter to type)? 

+1

But it might collide with other program names? Perhaps we should use a prefix for all of our binaries / scripts?

E.g:
 - odd-ksm
 - opendnssec-ksm
 - od-ksm

> b) What about an "interactive" mode, allowing a sequence of 
> ksm(util) commands to be entered (and state to be carried 
> across between commands)?

Something for the future.

> c) Regarding "-f config_dir", is there a case for a search path: 
> 
> i) if "-f config_dir" is specified on the command line, use that. 
> ii) Otherwise translate the environment variable 
> "OPENDNSSEC_CONFIGDIR" (or something) and use that
> iii) Else look in a default location? 

+1

> d) The form of the command is: 
> 
> % ksm(util) <verb> <flags> <arguments> 
> 
> ... where the verb is a single token.  In the examples above, 
> the command for rolling a zone is "rollzone <zone>" and the 
> command for rolling a policy is "rollpolicy <policy>".  Do we 
> want a more sophisticated parser that can take multiple words 
> to determine the action, e.g. "roll zone <zone>" and "roll 
> policy <policy>"? 
> e) Should we allow the parser to recognise unambiguous 
> abbreviations (e.g., "rollz" and "rollp" for the single token 
> case, perhaps "r z" and "r p" for the multi-word case)? 

Keep it simple. I think we only should allow one format for each command.

> ... and one specific observation: 
> 
> a) If we have "addzone" and "delzone", we should also have 
> "listzone". 

+1

> Agreed, although I would modify this to: 
> 
> "backup done [date]" 
> 
> ... where the default is the date/time at which the command 
> is issued.  This just covers the case where a backup is done 
> but the ksm command is not issued until some time later.  It 
> prevents keys created since the backup up being made 
> available prematurely. 

+1

> 
> We should also have 
> 
> "backup list" 
> 
> ... to list the date of last backup (dates of last backups?) 
> 

+1

> This raises a question as to where the master copy of the 
> policy should be.  At the moment, the XML file is read into 
> the database and all access to the policy is via the 
> database.  Why should we regard the XML as the master copy - 
> why not the contents of the database? 

The auditor wants a copy of the master copy. Is it wise to get the copy from the database?

> Another guideline I've always found useful: if you have "add 
> <something>" and "delete <something>" commands, you are 
> usually likely to want "list <something>" and "modify 
> <something>" as well. 

+1

// Rickard
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSktfXuCjgaNTdVjaAQix5QgAgvE7mhJnH03renbaIdxiC+TImgdeD18J
bsl2jhc6rPKyxnVk6ltnqocD6UlQTjQiK0aIZ6KYGkaek5x3iC04sdsPx8nn158Y
KgpEzk6N8nXcfx8xy1ABLbYZYh1H4bvEmiYpcb3bBYM76Ks4UCpgo8DvW5Rx82YN
zmgPRvs0J84qY2uAbS5sINwYzgp6i6Qt8DaCdeKVkMwTHZczri4SHfKyNZlRVVxZ
+D2xoab6MToUFYW1niCW/etzqv/AEN/n21KtoJCtxZDZTfF4Ko/ftFYeJuoB48Gj
IWhHRv1veyIjVYM6hMGs3JeHsFYcTJMMyjvQTi7UeBMLUlpO9YQPTg==
=PEss
-----END PGP SIGNATURE-----