Petr Viktorin wrote:
Please take a while to comment on this proposal before I post it on the
This is about user-visible changes I plan to make for #2652 (Framework
for admin/install tool) -- consistent behavior will (in addition to not
confusing users) enable the framework to do common work without too much

= Overview =

The output, logging, and command-line options of our install/management
tools are inconsistent. This RFE aims to clean up some of the

Specifically it addresses:
- Inconsistencies between console output and log files
- Tools using either --verbose or --debug used for the same purpose
And some collateral issues:
- The --version option missing in some tools
- The problem of e.g. an accidental ipa-server-install overwriting
ipaserver-install.log by the useless message, "The server is already

This is part of [|#2652
Framework for admin/install tools]

= Design=

Each command will have these command-line options (added automatically
by the framework):

   --version        show program's version number and exit
   -h, --help       show the help message and exit

   output and logging options:
     -q, --quiet    Output only errors
     -v, --verbose  Print debugging information
     --log-file     (alternate) log file name

The precise meanings of the output options are:
   (nothing): print INFO-level messages and above to stderr
   -q: only print ERROR-level messages and above to stderr
   -v: print all messages to stderr, prefixed with severity level
In all cases, if there is a log file, all messages go to it

In commands that currently have it, the `-d, --debug` option will become
a deprecated alias for --verbose.

Note that this RFE only adds new options, so backwards compatibility is

The tools will use the following log message severities:
- CRITICAL for fatal errors
- ERROR for critical things that the admin must see even in --quiet mode
- WARNING for things that need to stand out in the log
- INFO to display normal messages
- DEBUG to spam about everything the program does
- a plain print statement for things that should not be log, for
interactive prompting should use the console and follow up with a DEBUG
mentioning the final value

The commands check their arguments and most do some validation and
possible interactive prompting before doing any modification of the
system. Since the system is not changed, the user can always re-run with
--verbose if there are problems in this phase. Logging information from
this phase to a file is useless.
The file logging will start after the validation/prompting. The first
logged message(s) will mention the command and options used.

= Use Cases =

User runs some /usr/sbin/ipa-* commands with the --help option to see
that the logging-related options are the same in all of those programs.

User runs an ipa-* command with the -q option to only see errors.

User runs an ipa-* command (possibly with --log-file, if the command
doesn't log by default), and later reviews the log file to find all
relevant information.

= Implementation =

The RFE will be implemented gradually as new commands are ported to the

Can you list exactly which commands you're targetting?

At least some (ipa-replica-manage, ipa-replica-prepare) don't have logging but may still benefit from this structure. Did you have those in mind as well?

It may be time to rewrite ipa-upgradeconfig too. It started as a one-off and has grown considerably over the past year. It would benefit from this as well (though other enhancements would be beyond this scope).


Freeipa-devel mailing list

Reply via email to