RE: [logs] EventLog library

rgerhardsat_private

> > > Here's a sample program which builds an event record, shows it to 
> > > the user, and also sends it to the log:
> > > 
> > > #include "evtlog.h"
> > > #include <stdio.h>
> > > #include <errno.h>
> > > #include <stdlib.h>
> > > 
> > > int
> > > main(void)
> > > {
> > >   EVTREC *e;
> > 
> >     IDSA_CONNECTION *handle;
> >     IDSA_EVENT *msg;
> > 
> > >   evt_open("evtfmt", LOG_AUTH);
> > 
> >     handle=idsa_open(argv[0], NULL, 0);
> > 
> > So you are hiding global state from the user. Presumably
> > that means thread locking in or around evt_open/log ? For 
> the sake of 
> > getting a standard wrapper that is ok with me though, I can 
> hide the 
> > idsa_connection handle
> 
> I was under the impression that a single log 'connection' 
> will be used by a single application, therefore the global 
> state is stored in a single, global EVTCONFIG structure.

Mmmhhhh... Thinking twice, I would prefer to have a "log handle". Think
about an app that is expandable by plug-ins. Under Win32, you'll
probably do this as in-process dlls. Now the add-in has the problem of
knowing in what state the main app is. It is cleaner if each "user"
(code) can aquire (and hopefully free) his own handle....

> I think it is difficult to completely forget about syslog 
> severities though. The major transport for these messages 
> will be syslog. We either need a function to map some 'new' 
> priority field to standard syslog priority, _or_ we use 
> syslog priority and require the application to define its own 
> tag if it wants more.
> 
> The 11 valued field mjr has proposed was quite IDS specific. 
> The ones you use are IDSA specific, and I don't either of you 
> could work with the other's priority definition.

Again, I would vote for syslog pri/fac. Keep in mind people know how to
deal with this (well, at least some ;). This is a plus I would like to
drag over. I like a minimal change approach. The more you change, the
more you break. Especially when it comes to acceptance... (yes, I know I
went to far with this approach in the timestamp area - but I
nevertheless try ;)).
> > >   evt_tag_printf(e, 0, "test:printf", "%d %d", 5, 6);
> > 
> >     idsa_add_printf(msg, IDSA_LDM_PROTO, "HTTP/%d.%d", 1, 0);
> > 
> > >   es = evt_format(e);
> > >   printf("%s\n", es);
> > >   free(es);
> > 
> > I don't have that in idsalite
> 
> This function is needed only if the application wants to 
> perform its own logging but still wants to use the tagged 
> message format.

I think it is very useful. It should stay there...

> > 
> > > * tag naming, namespaces
> > >   not really the scope of this library but should be documented 
> > > somewhere
> > 
> > I have tag names in idsa_schemes.h. I have included the logging
> > data map under the namespace .ldm-1. I hope Marcus and Paul don't
> > object - I mailed them on Sunday.
> 
> I'll try to write something about tag naming.

I suggest we get Marcus on board (well, he already is ;))

> I'd prefer using XML namespaces for tag naming. Other opinions?

Sounds reasonable... Has prooven to solve this kind of problems...
Marcus?

Rainer
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis