directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <seelm...@apache.org>
Subject Re: Questionning some parts of the configuration
Date Thu, 11 Jun 2009 18:39:29 GMT
Hi Emmanuel,

Emmanuel Lecharny wrote:
>> I would suggest we clean up a bit all of this.
>>
>> 1) ApacheDS is a condensed name for ApacheDirectoryServer. It's a
>> server. we will keep the two services (Ldap and Ldaps), even if we
>> should treat them as transport, not service.
Hm, in 7) you write to only have one LdapServer. Do you also want to
remove the ApacheDS configuration element?

>> 2) All the other servers (NTP, DHCP, Kerberos, DNS) are a combinaison
>> of one or more transport and an optional DirectoryService, if needed.
+1
As far as I see the configuration this is already the case.

>> 3) We will define only one DirectoryService for LDAP. We may want 2
>> DirectoryServices, one for LDAP and another one for LDAPS. But this is
>> not what we have in ApacheDS atm (looking at the code, the
>> DirectoryService is define 3 times : in ApacheDS and in both
>> LdapService).
Do you mean there are three instances of DirectoryService or just
references?

>> 4) The consequence is that some flags like AllowAnonymousAccess is now
>> useless in ApacheDS, as it's already present in the LdapService
>> instances.
I don't see where the AllowAnonymousAccess flag will be defined in
future, in LdapServer or in DirectoryService or in both? And if in both,
would the configuration in LdapServer overwrite the configuration in
DirectoryService?

>> 5) The SyncOnWrite flag is define in a Service class, instanciated in
>> ApacheDS. That's most certainly not what we want, as it defines a
>> worker thread in charge of calling directoryService.synch()
>> periodically. This thread is specific to ApacheDS, and won't be
>> available to someone who want to use a DirectoryService as a server
>> backend. I suggest we move the Worker to DirectoryService.
+1

> 6) LdapService should be renamed to LdapServer. Everything associated
> with a Transport is a server, not a service.
+1, please rename it to Server.

> 7) We should be able to handle LDAP _and_ LDAPS in the LdapServer. Atm,
> it's done by declaring two LdapService, which is not a good idea, as its
> duplicate a lot of configuration elements. There is no difference
> between LDAP and LDAPS, except that we use SSL. Imo, it's just a matter
> of defining some new transport (different port, SSL enabled)
+1
One LdapServer with two Transports sounds perfect for me.

> 8) The transport class should e extended to enable or disable SSL.
+1
Plus the enableLdaps flag should be removed from the LdapServ[ice|er]
class, its enough to define an SSL-enabled transport.
What's not clear for me is how the SSL-enabled transport could access
the server certificate and key, if stored in "uid=admin,ou=system"
entry. Is the transport started from the LdapServer? Then the LdapServer
could pass it to the transport.


So my understanding is that the server will look like this in future, is
that correct?

--------------------------------------------------------------------
|   TCP   | SSL-TCP- |  TCP-   |  UDP-   |     |  TCP-   |  UDP-   |
| Transp. |  Transp. | Transp. | Transp. | ... | Transp. | Transp. |
--------------------------------------------------------------------
|    LDAP Server     |    DNS Server     | ... |     NTP Server    |
--------------------------------------------------------------------
|           Directory Service                  |
------------------------------------------------


Kind Regards,
Stefan

Mime
View raw message