On Sat, Nov 27, 2010 at 3:26 PM, Emmanuel Lecharny <[email protected]> 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
