[Opendnssec-develop] Unified Control Program (was -a vs --all)

[Rick van Rein]

Hi Stephen,

Sorry for missing your command description at first, I only glanced at the
message on top and mistook it for the entire message.

> The document describes the functionality of such an application (called, 
> for the purposes of this document, "odctl" [OpenDNSSEC Control]).

"odXXX[d]" could very well be the consistent naming format that I was
thinking about during the meeting.  For example,

   odsignd
   odkeygend
   odkaspd
   odauditd

and either

   odhsmutil	-or-	hsmutil
   odksmutil	-or-	ksmutil
   odsigutil	-or-	sigutil

(With the latter three combined in one, the "od" prefix shouldn't be a
 nuisance to the user.)

It'll also make it easier to do stuff like

	ps ax | grep ^od

The false positives of the latter are pretty much limited to people
making octal dumps of files I suppose :-)

> As noted above, a management program requires the ability to configure the 
> system.

I don't think of it being a requirement of odctl to edit config files,
but it definately is a bonus that helps to demonstrate what the use
of a strictly formatted configfile is (for example in XML).

> c) It is not clear that a CLI is the best way to edit the structured data 
> in the configuration files - a GUI may be a better option, although this 
> will entail much more work.

We have a basis of comparison for that.  The postconf command edits the
setup of Postfix, and I've heard people being enthousiastic about it.
I also find it much nicer during automated installs -- I'd much rather
specify "postconf relayhost=xx.yy.zz" than "echo something_crummy |
ed /etc/postfix/main.conf".  In other words, there are certainly good
sides to such CLI edits of configfiles, most notably surrounding
automation.

> b) The configuration files are still being altered as development 
> proceeds.  It will be better to wait until the format and contents have 
> settled down.

Unless you'd use the DTD to somehow be able to generically do the work
(or find a pre-existing library to do it for you).

> In subsystem mode, [...]
> Single command mode [...]

Looks sensible to me.

> ... which will invoke the odctl program, run the command (in this case, 
> "addzone") and exit odctl, returning control to the shell prompt.

I assume if "addzone" involves informing a number of daemons, setting up
configfiles, notifying daemons and such, that it will all be taken care
of?  And once a sanity check on the config is in place, that it will run
that too, a bit like apachectl checking on configfile syntax before it
fails on it during a restart?

> In practice, odctl will be a thin layer over functions in the OpenDNSSEC 
> libraries;

In theory I think :)  I'm sure this program too will start to lead a life
of its own.  Remember, always if you act on DNS, you open a can of worms.

> there should be little (if anything) that odctl does that 
> cannot be done by calling one of the library functions (this will 
> facilitate the creation of a GUI interface).

If however it can smoothe the path such that a single command arranges
all that needs to be done throughout OpenDNSSEC, it will do much more
than being a shell: it will uplift OpenDNSSEC to a user-friendly
platform!  It could be the "single button" that we all hope to press
one day.

> Functions  It could be the "single button" that we all hope to press
one day.  It could be the "single button" that we all hope to press
one day.

> odctl> source <file>
> Reads and executes odctl commands from the given file. (The commands 
> should be echoed to stdout before execution.)

Yeah, it really looks like a simple thin layer when you add includes ;-)

> odctl> start [-p hsm_password] [component]
> odctl> stop [component]
> odctl> restart [component]

Sometimes, there also is a use for "reload" which, at minimum, does the
same as "restart" but, ideally, reloads updated configuration without
any downtime.  Short downtimes aren't an issue for OpenDNSSEC but you
could still decide to honour this practice.

Of course, apachectl only supports "restart" but does a "reload" whenever
possible.

> List of Command Flags
> =====================

Long options as well?


Thanks, Stephen.

-Rick