How come failed authentications aren't ....

[David Collier-Brown]

Dan Kaminsky wrote:
> I think "Debug logs say what Samba is doing, my logs say what the *user* is
> doing" put it best.

	Hmmn: It's prefectly sane to build a logging
	facility that integrates with the normal samba
	logs but adds functionality to make it do a
	better "usr activity log"

	I reinvented one last year to add more tergeted
	functionality to syslog: the interface signature was:

void errlog(const int, const char *, ...);
void seterrline(const int, const char *, const char *, const char *);
void seterrseverity(const int);
void openerrlog(const char *, const int, const int);
void closeerrlog(void);

/*
 * The first (non-short) int of errlog really describes a packed
 * form of three extensable enumerations, similar to:
 * typedef struct severity {
 *      int     originOfProblem:  8; OTHER=0, INPUT or PROGRAM.
 *      int     attributes:  8; NONE=0, (used for runtime tracing,
actually)
 *      int     severity:   16; FATAL_ERROR=-1, RECOVERABLE_ERROR=0
 *                              WARNING, etc.
 * } severity_t;
 */

	This handled client-application error mesasages: a similar
	design could custom-fit server error messages (like Dan's)
	In this example, seterrline set the context (from an input
	file) in the main loop and the other routines could
	just call errlog() when they had a problem, knowing that
	the context would be printed.

	At severities from above warning, nothing went to syslog,
	just to the debug and tracing logs...  I eventually sed'd
	all the old debug statements into this format, but only
	in my Copious Spare Time (:-))

--dave
-- 
David Collier-Brown,  | Always do right. This will gratify some people
185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
Willowdale, Ontario   | http://java.science.yorku.ca/~davecb
Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb at canada.sun.com