On Sat, Nov 27, 2010 at 3:26 PM, Emmanuel Lecharny <firstname.lastname@example.org>
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.