directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <>
Subject Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Date Tue, 05 Jun 2007 23:38:19 GMT
On 6/5/07, Enrique Rodriguez <> wrote:
> On 6/5/07, Emmanuel Lecharny <> wrote:
> > ...
> > This is where I don't understand. The LDP request specify thet the bind
> is
> > SIMLPLE, not SASL, so I don't see a reason to pass through GSSAPI.May be
> I'm
> > plain wrong, maybe then the PLAIN mechanism should be used, but I don't
> > think this is the way to go. Can you elaborate a little bit?
> Sorry, you confused me by including a snippet of the "props" bean from
> the Spring XML, so I thought this was related to the back-end bind.
> That a remote client attempts a SIMPLE bind and sees the warning about
> GSSAPI not being properly configured is simply because the GSSAPI
> principal is re-tried on EVERY bind until one is found.  The idea was
> you'd see this warning and think "I need to obey the warning and add a
> service principal."  This would allow you to add the principal and
> have it get used without restarting the server.

Ok, I get it now. But nothing in the code nor in the javadoc explain this
behaviour, which is anything but trivial. Your last doco (
helped me a lot, and I wish I have it when I had all those problems, last

I agree that seeing a GSSAPI warning on a remote SIMPLE bind is
> misleading.  But, it is not the case that SIMPLE binds "pass through
> GSSAPI," only that binds are the trigger for re-checking the presence
> of a GSSAPI service principal.  I can add a conditional to only re-try
> finding a GSSAPI principal with GSSAPI requests.

Now that I understand what happens, I agree that the excpetion and the bind
are unrelated, or that they are simply related because you check the service
principal during a bind.

What I would suggest is :
- first of all, and even if it's a minor modification, just don't send a
full stack trace in the logs. It kills performance, and is not a good idea
for a warning level (when I see a stack trace, my brain immediately raise
the "BUG !" flag)
- I suggest that the Ldap configuration remains as simple as possible, and
as close as it was previously.

We will discuss further about which will be the next configuration scheme,
considering that a lot of work have been done related to this part of the
server. Not only your work, but also the guys working on LdapStudio (and the
ServerConfiguration editor plugin), but also the current discussion about
storing the configuration in the DIT.

We didn't want to include this new configuration before the SASL dust has
settled, this is why we asked for a delay before including it.

In the future, I want it to be clear that we need to avoid huge
modifications before everyone has evaluated the consequences on their parts,
as we now are a big team (we are now 8 active committers, 4 on Studio, 4 on
the server). This is not anymore easy to manage, and need more
communication, more documentation, and more carefull integration.

I know this will slow down the process, but I think it's almost impossible
to avoid having more rigid rules. I will try to set them up in the next few
weeks, if the PMCs aggreed.



Emmanuel L├ęcharny

View raw message