Trace logging project

[JC Ferguson]

Greg,

I replied on the Wiki with my thoughts.  Here are some additional thoughts:

- The trace logging must be able to be enabled and disable without restarting a program that calls MIT KRB5.  We have long-running programs and it would be disruptive to restart the program to enable logging, then restart it again to disable logging.

- also, we may have many processes running on one operating system instance, each calling MIT KRB5.  Ideally, we'd want to enable logging for one process, but not all.  

- Need different logging levels; i.e., 1=little bit, 2=more, 3=even more, 99=fill the disk up :).  Alternatively, if you did it per facility in the library, that may work also.  There should be an option to write keys out the trace log, with all the normal caveats about security.  Sometimes, we have bizarre issues with changing session/long-term keys in the environments we interoperate in.

- May want to consider limiting the size of the log to avoid the "oops, I forgot to disable logging" problem that may turn up.  What I have done that works well in commercial production applications is maintain two log files - Kerberos.log and Kerberos.log.1.  kerberos.log, when filled to some pre-specified size, get renamed to Kerberos.log.1, then it restarts.

- regarding the context requirement, so long as that is buried under the covers and the interfaces to the API don't change, I'm good with it.

- the format of the log should include the time, pid, some sort of facility identifier, then the text - this'll help with finding the needed in the haystack as you can eliminate things you don't care about using 'grep -v' when doing post-mortem analysis.

I'll check the Wiki also.

2 cents

-jc

> -----Original Message-----
> From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf Of Greg
> Hudson
> Sent: Saturday, September 12, 2009 0:14
> To: krbdev at mit.edu
> Subject: Re: Trace logging project
> 
> On Fri, 2009-09-04 at 17:17 -0400, ghudson at MIT.EDU wrote:
> > Based on recent feedback from krb5 users, I've written up an early
> > project page on trace logging:
> 
> It sounds like no one has strong opinions about this, which is fine;
> it's not going to be very intricate.
> 
> I'm going to start with a simple binary switch: you turn on tracing (by
> specifying a filename in KRB5_TRACE) and you get everything.  If there
> turns out to be a need for pre-filtering, that can be added later,
> although it will of course mean marking up all of the existing trace
> calls.
> 
> Trace calls will require a context.  I don't think there's any important
> code to trace with no access to a context, and it makes it simple to
> avoid tracing for secure contexts.
> 
> When I went to add my first tracing call, I realized that we'll need a
> custom formatter to deal with principal names and krb5_data structures
> and the like.  Fortunately, there already is one in
> lib/krb5/os/sendto_kdc.c, which was easy to adapt.
> 
> I've adjusted the project page and kicked into review status, with an
> end date of September 18th (one week).  I have the plumbing written now,
> and can commence the work of littering the code base with tracing calls.
> 
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev