directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Kerberos codec and other codec, and a bit of 'state of the nation'
Date Sat, 27 Nov 2010 17:41:56 GMT
On Sat, Nov 27, 2010 at 3:26 PM, Emmanuel Lecharny <>wrote:

> Hi guys,
> first, I'm please to inform you all that the Kerberos protocol codec has
> been completed today. It was a painful job, with more than 30 000 slocs
> generated. Now, it's time to include this work into the kerberos server.
Great job guys. This was an incredible effort.

> Atm I'm reviewing what we have done, and try to clean up the thing, as the
> code we wrote at the end is different from what we started with, as we
> improved the process a lot. There are a few points I think worth discussing.
> - The loggers. Currently, we use a per class logger. I think it's
> inaccurate, as we won't be able to group all the logs for a specific
> protocol in one single logger. Of course, if we want to disable the codec
> logs, we can always do that by filtering on the package, but I think we
> could also decide to generate all the logs into one single logger, called
> "CODEC". wdyt ?
I think the current per class way works and filtering on the package name is
the way to go via the log4j properties file.

> - The tests. Right now, testing that the decoder is correct is a burden. We
> discussed a lot about it, and we didn't found a convenient case to test all
> the possible wrong PDU we should reject. We need a tool for that, but I
> doubt a tool can be written in less than a few weeks. Thoughts ?
There's a way but it's long and exhaustive. If we can find a new contributor
willing to take this on maybe as a background thread I'd be glad to guide
them on it.

> Otherwise, we will now have to include the codecs into the Kerberos server,
> and hopefully solve the problem we had with Kerberos on top of TCP. That
> could take a day.
> We will then have to check the Kerberos server itself. I'm afraid that we
> might be surprised by the way it works, not in a positive way, sadly.

Yes I agree - but finally we're going to have this beast tamed.

> We need some client tests, so we need to setup a test env that allows us to
> test the Kerberos server using some kerberos client we may write. In order
> to check that those kerberos client code is OK, we need to compare it with
> what Java is providing. I guess that it will take a bit of time, but I
> really see the Kerberos server as a major asset.

> On the LDAP server side, we still have to work on the Administrative Point
> management. I will do that on december, and I think it can be available by
> mid-december.
I'll lend a hand on this. The AP issues are really important to get right
once and for all.

We are close. Really close. The configuration management is doing OK, we
> soon will have a decent UI to administer the server. Pierre-Arnaud is also
> thinking about the best way to extend the configuration, when an implementer
> want to add his own configuration for some of the extension points. He
> should come with somethng working by mid-december too.

Alex Karasulu
My Blog ::
Apache Directory Server ::
Apache MINA ::
To set up a meeting with me:

View raw message