<tt><font size=2>Jakob Schlyter <jakob@kirei.se> wrote on 01/07/2009
12:22:28:<br>
<br>
> On 1 jul 2009, at 07.16, sion@nominet.org.uk wrote:<br>
> <br>
> > I'm getting on with ksmutil now (the replacement for kaspimport
and <br>
> > all of<br>
> > its perl dependencies). My question is, what do people expect
from it?<br>
> ><br>
> > Currently the usage reports:<br>
> ><br>
> > usage: ksmutil [-f config_dir] setup [path_to_kasp.xml]<br>
> > Import config_dir into a database
(deletes current contents)<br>
> > usage: ksmutil [-f config_dir] update [path_to_kasp.xml]<br>
> > Update database from config_dir<br>
> > usage: ksmutil [-f config_dir] addzone zone [policy]<br>
> > [path_to_signerconf.xml] [input] [output]<br>
> > Add a zone to the config_dir and database<br>
> > usage: ksmutil [-f config_dir] delzone zone<br>
> > Delete a zone from the config_dir
and database<br>
> > usage: ksmutil [-f config_dir] rollzone zone [KSK|ZSK]<br>
> > Rollover a zone (may roll all zones
on that policy)<br>
> > usage: ksmutil [-f config_dir] rollpolicy policy [KSK|ZSK]<br>
> > Rollover all zones on a policy<br>
> <br>
> -f config_dir is more like [-f config] for the main config file I
<br>
> hope. all other params can be derived from it.</font></tt>
<br>
<br><tt><font size=2>Some general observations:</font></tt>
<br>
<br><tt><font size=2>a) Would "ksm" be better than "ksmutil"
(shorter to type)?</font></tt>
<br><tt><font size=2>b) What about an "interactive" mode, allowing
a sequence of ksm(util) commands to be entered (and state to be carried
across between commands)?</font></tt>
<br><tt><font size=2>c) Regarding "-f config_dir", is there a
case for a search path:</font></tt>
<br>
<br><tt><font size=2>i) if "-f config_dir" is specified on the
command line, use that.</font></tt>
<br><tt><font size=2>ii) Otherwise translate the environment variable "OPENDNSSEC_CONFIGDIR"
(or something) and use that</font></tt>
<br><tt><font size=2>iii) Else look in a default location?</font></tt>
<br>
<br><tt><font size=2>d) The form of the command is:</font></tt>
<br>
<br><tt><font size=2>% ksm(util) <verb> <flags> <arguments></font></tt>
<br>
<br><tt><font size=2>... 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>"?</font></tt>
<br><tt><font size=2>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)?</font></tt>
<br>
<br><tt><font size=2>... and one specific observation:</font></tt>
<br>
<br><tt><font size=2>a) If we have "addzone" and "delzone",
we should also have "listzone".</font></tt>
<br>
<br>
<br><tt><font size=2>> <br>
> ><br>
> > (don't get excited, it doesn't do all of this yet)<br>
> ><br>
> > So, what else do we need it to do? Some ideas:<br>
> ><br>
> > "backup done"<br>
> <br>
> yes.</font></tt>
<br>
<br><tt><font size=2>Agreed, although I would modify this to:</font></tt>
<br>
<br><tt><font size=2>"backup done [date]"</font></tt>
<br>
<br><tt><font size=2>... 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.</font></tt>
<br>
<br><tt><font size=2>We should also have</font></tt>
<br>
<br><tt><font size=2>"backup list"</font></tt>
<br>
<br><tt><font size=2>... to list the date of last backup (dates of last
backups?)</font></tt>
<br>
<br><tt><font size=2><br>
> <br>
> > "add repository"<br>
> > "remove repository"<br>
> <br>
> these are all done by editing the main config file.<br>
> <br>
> > "add policy"<br>
> > "remove policy"<br>
> <br>
> these are done by editing the KASP and reimported. IMHO, import should
<br>
> REPLACE all existing policies, i.e. the import is more of a one-way
<br>
> replace.</font></tt>
<br><tt><font size=2>> <br>
> > "copy policy"</font></tt>
<br><tt><font size=2>> <br>
> where to?<br>
> <br>
> "export policy", dumping the database as KASP, would be
nice. as well.</font></tt>
<br>
<br><tt><font size=2>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?</font></tt>
<br>
<br><tt><font size=2>Assuming that import and export functions are provided,
then editing a policy with a text editor would be the sequence:</font></tt>
<br>
<br><tt><font size=2>* export policy to XML</font></tt>
<br><tt><font size=2>* edit XML</font></tt>
<br><tt><font size=2>* import and replace policy</font></tt>
<br>
<br><tt><font size=2>... whereas a more sophisticated editing tool might
access the database directly.</font></tt>
<br>
<br><tt><font size=2>If we take this view, then I suggest we need:</font></tt>
<br>
<br><tt><font size=2>import [-r | -d] file</font></tt>
<br><tt><font size=2>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.)</font></tt>
<br>
<br><tt><font size=2>export file [policy [policy ...]]</font></tt>
<br><tt><font size=2>Exports the named policies to a file. If no
policies are given, all policies are exported.</font></tt>
<br>
<br><tt><font size=2>list [-z]</font></tt>
<br><tt><font size=2>Lists a summary of the policies (e.g. names of the
policies and, if -z is specified, the zones associated with them).</font></tt>
<br>
<br>
<br>
<br><tt><font size=2>> > "edit policy" might need some
sort of interactive command line <br>
> > interface,<br>
> > the code for which is lurking around out of subversion.<br>
> <br>
> yes, we can do that later I believe. it might even be a separate <br>
> program (or a rails app).</font></tt>
<br><tt><font size=2>> <br>
> > "import keys" (keys created somewhere other than keygend)<br>
> <br>
> yes, that is important. import should take a CKA_ID, a zone and a
key <br>
> type and state?<br>
> <br>
> > "list [keys|policies|etc]"<br>
> <br>
> yes, please.<br>
> <br>
> > Hmm, the more I think about it, the more 5 pivotal points doesn't
seem<br>
> > anywhere near enough... I'll stop thinking.<br>
> <br>
> just add additional stories - it's usually a bad idea to try to <br>
> squeeze to much into one story. make one story per feature instead
and <br>
> you also get the feeling your're getting somewhere :-)</font></tt>
<br><tt><font size=2>> <br>
> jakob</font></tt>
<br>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>Stephen<br>
<br>
</font></tt>