[Opendnssec-develop] ksmutil

[Stephen.Morris at nominet.org.uk]

Jakob Schlyter <jakob at kirei.se> wrote on 01/07/2009 12:22:28:

> On 1 jul 2009, at 07.16, sion at nominet.org.uk wrote:
> 
> > I'm getting on with ksmutil now (the replacement for kaspimport and 
> > all of
> > its perl dependencies). My question is, what do people expect from it?
> >
> > Currently the usage reports:
> >
> > usage: ksmutil [-f config_dir] setup [path_to_kasp.xml]
> >        Import config_dir into a database (deletes current contents)
> > usage: ksmutil [-f config_dir] update [path_to_kasp.xml]
> >        Update database from config_dir
> > usage: ksmutil [-f config_dir] addzone zone [policy]
> > [path_to_signerconf.xml] [input] [output]
> >        Add a zone to the config_dir and database
> > usage: ksmutil [-f config_dir] delzone zone
> >        Delete a zone from the config_dir and database
> > usage: ksmutil [-f config_dir] rollzone zone [KSK|ZSK]
> >        Rollover a zone (may roll all zones on that policy)
> > usage: ksmutil [-f config_dir] rollpolicy policy [KSK|ZSK]
> >        Rollover all zones on a policy
> 
> -f config_dir is more like [-f config] for the main config file I 
> hope. all other params can be derived from it.

Some general observations:

a) Would "ksm" be better than "ksmutil" (shorter to type)?
b) What about an "interactive" mode, allowing a sequence of ksm(util) 
commands to be entered (and state to be carried across between commands)?
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?

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)?

... and one specific observation:

a) If we have "addzone" and "delzone", we should also have "listzone".


> 
> >
> > (don't get excited, it doesn't do all of this yet)
> >
> > So, what else do we need it to do? Some ideas:
> >
> > "backup done"
> 
> yes.

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.

We should also have

"backup list"

... to list the date of last backup (dates of last backups?)


> 
> > "add repository"
> > "remove repository"
> 
> these are all done by editing the main config file.
> 
> > "add policy"
> > "remove policy"
> 
> these are done by editing the KASP and reimported. IMHO, import should 
> REPLACE all existing policies, i.e. the import is more of a one-way 
> replace.
> 
> > "copy policy"
> 
> where to?
> 
> "export policy", dumping the database as KASP, would be nice. as well.

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?

Assuming that import and export functions are provided, then editing a 
policy with a text editor would be the sequence:

* export policy to XML
* edit XML
* import and replace policy

... whereas a more sophisticated editing tool might access the database 
directly.

If we take this view, then I suggest we need:

import [-r | -d] file
Imports a policy file.  "-r" forces replacement of policies with identical 
names.  Without this, a duplicate policy name causes an error.  "-d" 
deletes all policies before the import. (Importing a single policy without 
replacing others allows the possibility (for example) of the publication 
of example policies on the web site - people could download and import 
them without affecting their existing setup.)

export file [policy [policy ...]]
Exports the named policies to a file.  If no policies are given, all 
policies are exported.

list [-z]
Lists a summary of the policies (e.g. names of the policies and, if -z is 
specified, the zones associated with them).



> > "edit policy" might need some sort of interactive command line 
> > interface,
> > the code for which is lurking around out of subversion.
> 
> yes, we can do that later I believe. it might even be a separate 
> program (or a rails app).
> 
> > "import keys" (keys created somewhere other than keygend)
> 
> yes, that is important. import should take a CKA_ID, a zone and a key 
> type and state?
> 
> > "list [keys|policies|etc]"
> 
> yes, please.
> 
> > Hmm, the more I think about it, the more 5 pivotal points doesn't seem
> > anywhere near enough... I'll stop thinking.
> 
> just add additional stories - it's usually a bad idea to try to 
> squeeze to much into one story. make one story per feature instead and 
> you also get the feeling your're getting somewhere :-)
> 
>    jakob


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.

Stephen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090701/8f2be8b0/attachment.htm>