KDC Audit project

[Dmitri Pal]

On 01/14/2013 11:02 PM, Nico Williams wrote:
> On Mon, Jan 14, 2013 at 9:31 PM, Dmitri Pal <dpal at redhat.com> wrote:
>> On 01/14/2013 09:59 PM, Nico Williams wrote:
>>>> No but the path management is the least thing you need for the the
>>>> logging itself.
>>> Indeed, but for *parsing* log entries path functions are quite handy.
>> But this is out of the scope of the current project. This is a part of
>> the server that would do analytics.
>> I doubt that any of the logging plugin implementations would need this
>> functionality.
> Huh?  Sure I'd need the functionality to parse a log entry.
Oh well... you might need it but the caller i.e. someone who will use
your library does not need to know that you need it.
This is your implementation detail, your choice to implement the trees.
It should be under the hood.

The more I get info from you the more is see it to be very basic low
level tool set while I am looking at a consumer friendly simple
interface that hides all these implementation details.
I do not care how json-c stores object internally it hides this
machinery from me.

While the tools are generic the event object to be logged is much less
generic. We can make a bunch of assumptions about it.
It will contain a timestamp, mostly it will be KVP, keys are stings,
values are of different types, occasionally you can have a list (array)
of the similar values (list of IP addresses for example), there is a set
of common keys that are usually a part of the event (there is a lot of
research on that, look in CEE and lumberjack, no need to invent the
wheel), the events will be in 99% one level collections so it is OK to
assume that they will be flat at least in the first implementation, the
order of the KVPs will be preserved, there will be conventions about
which attributes should go first, there is a simple way to traverse and
serialize etc.
All this most likely can be accomplished with the library you propose
but you would have to do all the heavy lifting yourself while with
something like json-c you do not need to build a wrapper or the wrapper
will be very thin and simple.

If you want haimbase to be used you are signing yourself for building a
wrapper around it to provide a very simple interface that is tuned for
event construction and traversal. Are you up for it or we would take
something off the shelf?
 
 

>
>> If the path is a value it should be just sent to the right destination
>> as is.
> Er, no... a path is just a way to address part of a tree structure
> (composed of dicts and arrays).
>
>>>> You might want to consider merging your library with ding-libs or
>>>> copying code from ding-libs.
>>> Link?
>> http://git.fedorahosted.org/cgit/ding-libs.git/tree/
> Thanks.
>
>>> I really don't understand what you think heimbase is missing.  It does
>>> nesting as you describe.
>> As you said it misses the traversal. Also dictionary usually does not
>> preserve the order while lists, arrays and trees do so dictionary of a
>> small value for event logging. Getting things out of order kills
>> serialization.
> Well, it's trivial to use the iterators to build a pre-/in-/post-order
> traversal.  That should be part of the API though, I agree.
>
> And you want a dict that preserves insertion order.  That is one thing
> that's missing, sure.
>
>> My last point is that heimbase and ding-libs are one offs and going to
>> rot over time because they are consumed by a very limited number of
>> projects while things like JSON libraries have a good chance to survive
>> our retirement as they are used by many consumers.
> I don't think that's necessarily true.  I want heimbase to be adopted
> by others.  If all say no because others haven't adopted it then... it
> still won't rot because Heimdal uses it and depends on it, so it will
> at least continue to work as well as it does now.

Well, SSSD depends on the ding-libs big time but I am sure that one day
it will switch to something else if it would be better maintained and
would be more suitable for its needs.

>
>>> Possibly, but such a layer seems like just so much overhead.  Better
>>> pick just one library.
>> Agree. This is last resort for the case when we can't get to the
>> consensus  :-)
> Please, let's not add a pluggable JSON library layer.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/