directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: Kerberos codec and other codec, and a bit of 'state of the nation'
Date Sat, 27 Nov 2010 13:32:53 GMT
On Sat, Nov 27, 2010 at 3:26 PM, Emmanuel Lecharny <elecharny@gmail.com> 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.
>
many thanks for the great 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 ?
>
IMO this should be the way to go, how about KRB-CODEC
> - 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 ?
>
rather than that am thinking that let us invest that time on writing a
krb client and we can test it against ours and MIT krb server and
compare the results and apply fixes if needed
> 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. 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.
>
> 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.
>
> That's pretty much it for today, I guess that it would be valuable if
> everyone of you working on the server give some feedback about what's going
> on, as we are slowly converging to a viable 2.0 !
>
> Thanks for listening !
>
> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny
> www.iktek.com
>
>

thanks Emmanuel

-- 
Kiran Ayyagari

Mime
View raw message