directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Questionning some parts of the configuration, proposal
Date Sat, 13 Jun 2009 05:56:24 GMT
Emmanuel Lecharny wrote:
> A few more things at the end of this mail ...
> Emmanuel Lecharny wrote:
>> Hi guys,
>> as I'm trying to figure out a DiT based configuration for ADS, I'm 
>> now questioning some choice that have been made long ago. I think we 
>> can simplify the configuration a bit.
>> Let's start with some preliminary comments.
>> - the base for all the storage is a DirectoryService. This is the 
>> heart of our system.
>> - we have built a lot of servers on top of it, like Kerberos, DHCP, 
>> DNS, ChangePW and LDAP. Those servers rely on the DirectoryService
>> - we have one unique server, NTP, which is standalone - ie, it does 
>> not need any DirectoryService -.
>> - the Ldap server is a bit special, as it is not named LdapServer, as 
>> we would expect when we have a look at the other servers, but 
>> ApacheDS, and it points to 2 LdapService (which in turn associate a 
>> DirectoryService with a transport)
>> - a Transport is a protocol layer defining the host, port, protocol 
>> and some other network related parameters. Each server has at least 
>> one transport.
>> Ok, so far, we are lost now :)
>> 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.
>> 2) All the other servers (NTP, DHCP, Kerberos, DNS) are a combinaison 
>> of one or more transport and an optional DirectoryService, if needed.
>> 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).
>> 4) The consequence is that some flags like AllowAnonymousAccess is 
>> now useless in ApacheDS, as it's already present in the LdapService 
>> instances.
>> 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.
> 6) LdapService should be renamed to LdapServer. Everything associated 
> with a Transport is a server, not a service.
> 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)
> 8) The transport class should e extended to enable or disable SSL.
Ok, I have changed a bit the code in order to fix some of the pitfalls I 
described. Before committing in trunk, I would like to expose what I 
have changed.

1) Transport
The transport classes (TcpTransport and UdpTransport) have been slightly 
changed. A new flag has been added to these class , enableSSL. It allows 
the transport to inject the SSL filter into the chain, if needed. It 
will be used for LDAP only.

2) ProtocolService
This class is the base for all the Server classes (NtpServer, 
ChangePaswordServer, KdcServer, DnsServer and LdapService). The 
getDatagramAcceptor and getSocketAcceptor methods now take a Transport 
as an argument (that means a Server may support more than one Transport, 
like LDAP which support a TcpTransport with or without SSL)

3) LdapService
This class is now used only once in the ApacheDS class, as we don't need 
to define one instance to manage LDAP and another one for LDAPS : both 
are managed through a different transport. As a consequence, a flag is 
removed (enableSSL) : this flag depends on the SSL enabled transport 
The getPort() method has been completed with a getportSSL() which 
returns the LDAPS associated transport port. The getPort() now returns 
the port for the non SSL transport.

4) ApacheDS
This class encapsulated the LdapServer and all the other servers. As a 
direct consequence of the transports modifcations, I have move dmost of 
the specific configuration up to the LdapService. The second impact is 
that we don't need to instanciate twice the LdapService (one for LDAP 
and anotherone for LDAPS), plus the reference to DirectoryService is now 
useless, as it's already present in the unique LdapService instance.

5) Server.xml
The server.xml file is impacted. Here are the main differences :
o The apacheDS bean is simplified :

  <apacheDS id="apacheDS">

instead of

  <apacheDS id="apacheDS"

As we now have only one LdapService, we don't need anymore to associate 
a DirectoryService to the ApacheDS class. The synchPeriodMillis has been 
removed, and must be moved to the DirectoryService, with the associated 
thread, as it's not ApacheDS business to sync the changes on disk. Last, 
not least, the allowAnonymousAccess flag is not needed anymore, as it's 
also carried by the LdapService.

o The LdapService bean has also been slighly modified, so that it can 
take more than one transport :

  <ldapService id="ldapService"...>
      <tcpTransport id="tcp-ldap" port="10389" nbThreads="8" 
backLog="50" enableSSL="false"/>
      <tcpTransport id="tcp-ldaps" port="10686" enableSSL="true"/>

instead of

  <ldapService id="ldapService"...>
      <tcpTransport port="10389" nbThreads="8" backLog="50"/>

(Note that <tcpTransports> is now plural)

o Idem for the other servers :

      <tcpTransport port="8053"/>
      <udpTransport port="8053"/>

instead of

      <tcpTransport port="8053"/>
      <udpTransport port="8053"/>

The only difference is the 's' at the end of tcpTransport.

Here we are, I'm done with this cleanup. The configuration hasn't 
changed radically, but it will be much easier to store it in the DiT.

Time for comments !

Thanks !

cordialement, regards,
Emmanuel L├ęcharny

View raw message