directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject Some heads-up
Date Fri, 15 Feb 2013 12:31:00 GMT
Hi guys,

Im been working on a few critical things those last few days. Let' me
explain what's going on !

- First, we have found a really annoying issue when the server is
stopped and started again : if you have a lot of entries in the server,
it takes forever to start the server. The reason is that the
AdministrativePoint intercetpor is trying to find all the entries with
an AdministrativeRole AT, and as this AT is not indexed by default, it
does a full scan, which is extremely expensive.

I fixed this issue by adding the AdministrativeRole AT to the System
indexes, pklus a few other changes, and the server bow restarts very

- Second, as I was working on the kerberos code, I discovered a HuGE
security breach : it was possible, if you disable the
SimpleAuthenticator, to log with any user, any pasword (they didn't even
have to be present in the server, nor the password to exist). The way it
was working was simple : if we didn't found any Athenticator for the
requested level (SIMPLE, SASL or anonymous), the
AuthenticationInterceptor was delegating authentication to the backend,
which was basically doing nothing, but return true.

I removed this call to the backend, and fixed some other issue (a NPE).

I'm now trying to fix anothe problem : since I activated the
transactions in JDBM, additions is extremely slow (I can go up to 50 add
per second with 10 indexes, but the more indexes you add, the slower it is).

The way transactions works in JDBM is pretty simple : a journal is
created, and on a regular basis (every N transactions), the journal is
flushed on disk. The N value is curently 1, so we flush everything for
every transaction, which is probably a bit too much. There are some
aspects that are not easy to deal with, namely transactions are Table
based, and we have many table supdated when a single addition is done,
some Table being updated more than once (RDN table, for instance).

I have still to find the best tuning for this problem. We were able to
inject 600 entries per second a year ago, so we should be able o go faster.

At the same time, I try to get the Kerberos documentation updated, which
is quite a challenge...

Stay tuned !

Emmanuel L├ęcharny 

View raw message