directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Kerberos codec and other codec, and a bit of 'state of the nation'
Date Sat, 27 Nov 2010 13:26:10 GMT
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.

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 ?

- 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 ?

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


Mime
View raw message