[Opendnssec-develop] ksmutil

[sion at nominet.org.uk]

I'm replying to Jakob's and Stephen's comments in one...

> > > 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.

Except for kasp.xml... either works, I was thinking that the directory is
where all of the files (.xml and .rng) are. I am happy to change it so that
you specify the conf.xml and it is assumed that everything else is in the
same place.

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

I'm more concerned with getting the functionality covered, rather than the
exact commands that will be typed.
The interactive mode would come eventually (possibly as part of "edit
policy").

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

Yes.

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

Okay.

> > > "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.

So my idea was that "add [something]" would add it to both the xml and the
database.
Copy policy would make a new policy from an existing one, which could then
be edited. Really just a way of getting most of it setup and allowing you
to tweak just those parameters that you want to.

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

This looks like a bigger can of worms than I thought. rails app implies
that the database is the definitive copy of the policy, use of import
implies that the xml is. Shall we say that until a GUI policy editor exists
then the xml is definitive and editing the file and re-importing is okay.
I'll add export policy to the wish list.

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

important for alpha or beta?

> > > "list [keys|policies|etc]"
> >
> > yes, please.

Okay.

> 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.

Okay. Pivotal doesn't seem to have any concept of priority as far as I can
see, or am I missing something?