Trace logging project

[Greg Hudson]

On Mon, 2009-09-14 at 17:00 -0400, Nicolas Williams wrote:
> So what is the real goal?

We received two independent requests in the course of one week, from
different angles.  I'll present them as use cases:

1. You market an application which uses Kerberos as a core component.
You are experiencing rare, inexplicable failures in customer
deployments.  You want to be able to collect more information about
failures in order to reproduce and debug them.

2. You market a server product with Kerberos support.  Your customers
are having trouble properly configuring clients to talk to a KDC and
your server product.  When they experience failures, they typically
can't tell if the problem is arising because of the client
configuration, the server configuration, the KDC configuration, or the
communication path between two of those components.  You want to be able
to collect more information about failed operations in order to identify
the configuration error.

Use case #1 arguably wants a facility oriented towards code debugging,
not configuration debugging, and it's possible that it's better fodder
for a generic tool--though I'm not sure the right tools exist in most
runtime environments, especially when you don't get to ship
specially-compiled debugging code to the customer as part of the support
process.  At any rate, a trace logging tool suitable for use case #2
could still be of assistance for #1, even if it's not a perfect fit.

In use case #2, the client failure is typically coming from a program
you didn't write, which may not have a rich interface for displaying
errors.

>From elsewhere in the thread:
> Context initialization _failures_ are interesting.

It seems like context initialization failures are about the simplest
type of possible krb5 failure, and can easily be captured in the text of
a simple error message.

Regardless, the point is likely moot; context initialization failures
can likely be traced using the half-constructed context.