You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@apache.org> on 2009/06/13 07:56:24 UTC
Questionning some parts of the configuration, proposal
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
presence.
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">
<ldapService>#ldapService</ldapService>
</apacheDS>
instead of
<apacheDS id="apacheDS"
synchPeriodMillis="15000"
allowAnonymousAccess="false">
<directoryService>#directoryService</directoryService>
<ldapService>#ldapService</ldapService>
<ldapsService>#ldapsService</ldapsService>
</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"...>
<tcpTransports>
<tcpTransport id="tcp-ldap" port="10389" nbThreads="8"
backLog="50" enableSSL="false"/>
<tcpTransport id="tcp-ldaps" port="10686" enableSSL="true"/>
</tcpTransports>
instead of
<ldapService id="ldapService"...>
<tcpTransport>
<tcpTransport port="10389" nbThreads="8" backLog="50"/>
</tcpTransport>
(Note that <tcpTransports> is now plural)
o Idem for the other servers :
<dnsServer>
<tcpTransports>
<tcpTransport port="8053"/>
</tcpTransports>
<udpTransports>
<udpTransport port="8053"/>
</udpTransports>
<directoryService>#directoryService</directoryService>
</dnsServer>
instead of
<dnsServer>
<tcpTransport>
<tcpTransport port="8053"/>
</tcpTransport>
<udpTransport>
<udpTransport port="8053"/>
</udpTransport>
<directoryService>#directoryService</directoryService>
</dnsServer>
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
www.iktek.com
directory.apache.org
Re: Questionning some parts of the configuration, proposal
Posted by Emmanuel Lecharny <el...@apache.org>.
Accordingly to Stefan,'s suggestions, I have slightly refactored the
codee again, and it's much better now. Let's see the differences :
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 LdapServer). 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 has been renamed LdapServer. It 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 presence.
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) The Sync On Disk thread has been moved from the Service class to the
DirectoryService class, and can be configured in this class (the
syncPeriodMillis property has been moved to this class)
5) 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 LdapServer. The second impact is
that we don't need to instanciate twice the LdapServer (one for LDAP and
anotherone for LDAPS), plus the reference to DirectoryService is now
useless, as it's already present in the unique LdapServer instance.
6) Server.xml
The server.xml file is impacted. Here are the main differences :
o The apacheDS bean has been simplified :
<apacheDS id="apacheDS">
<ldapService>#ldapServer</ldapService>
</apacheDS>
instead of
<apacheDS id="apacheDS"
synchPeriodMillis="15000"
allowAnonymousAccess="false">
<directoryService>#directoryService</directoryService>
<ldapService>#ldapService</ldapService>
<ldapsService>#ldapsService</ldapsService>
</apacheDS>
As we now have only one LdapServer, we don't need anymore to associate a
DirectoryService to the ApacheDS class. The synchPeriodMillis has been
removed, and has beento 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 LdapServer.
o The LdapService bean has also been renamed LdapServer and has been
modified, so that it can take more than one transport :
<ldapServer id="ldapServer"...>
<tcpTransports>
<tcpTransport id="tcp-ldap" port="10389" nbThreads="8" backLog="50"
enableSSL="false"/>
<tcpTransport id="tcp-ldaps" port="10686" enableSSL="true"/>
</tcpTransports>
instead of
<ldapServer id="ldapServer"...>
<tcpTransport>
<tcpTransport port="10389" nbThreads="8" backLog="50"/>
</tcpTransport>
(Note that <tcpTransports> is now plural)
o Idem for the other servers :
<dnsServer>
<tcpTransports>
<tcpTransport port="8053"/>
<udpTransport port="8053"/>
</udpTransports>
<directoryService>#directoryService</directoryService>
</dnsServer>
instead of
<dnsServer>
<tcpTransport>
<tcpTransport port="8053"/>
</tcpTransport>
<udpTransport>
<udpTransport port="8053"/>
</udpTransport>
<directoryService>#directoryService</directoryService>
</dnsServer>
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Questionning some parts of the configuration, proposal
Posted by Emmanuel Lecharny <el...@apache.org>.
Stefan Seelmann wrote:
>> 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
>> presence.
>> 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.
>>
> Would be good to rename it to _LdapServer_, just to be consistent to the
> naming of the other servers.
>
Most certainly. At least, it will be consistent.
Now, https://issues.apache.org/jira/browse/DIRSERVER-1140 did the exact
opposite move, I have no idea why...
>
>> 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.
>>
> Emmanuel and I just discussed on IRC, it should be possible to get rid
> of the ApacheDS class because it just grouped the LdapServices.
>
Yop. Will do that.
>
>> o The LdapService bean has also been slighly modified, so that it can
>>
> LdapServer?
>
yes.
>
>> <dnsServer>
>> <tcpTransports>
>> <tcpTransport port="8053"/>
>> </tcpTransports>
>> <udpTransports>
>> <udpTransport port="8053"/>
>> </udpTransports>
>> <directoryService>#directoryService</directoryService>
>> </dnsServer>
>>
>
> This transports configuration looks a bit chatty. A simpler solution
> could be:
>
> <...Server>
> <transports>
> <tcpTransport .../>
> <udpTransport .../>
> </transports>
> </...Server>
>
> Or
>
> <...Server>
> <tcpTransport .../>
> <udpTransport .../>
> </...Server>
>
Sure ! Will do.
I suggest that we allow both syntax. if a server has only one transport
(for TCP/UDP), then the second syntax will be used. If a server can have
more than one syntax, then we will use the first one.
Thanks Stefan !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Questionning some parts of the configuration, proposal
Posted by Stefan Seelmann <se...@apache.org>.
> 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
> presence.
> 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.
Would be good to rename it to _LdapServer_, just to be consistent to the
naming of the other servers.
> 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.
Emmanuel and I just discussed on IRC, it should be possible to get rid
of the ApacheDS class because it just grouped the LdapServices.
> o The LdapService bean has also been slighly modified, so that it can
LdapServer?
> <dnsServer>
> <tcpTransports>
> <tcpTransport port="8053"/>
> </tcpTransports>
> <udpTransports>
> <udpTransport port="8053"/>
> </udpTransports>
> <directoryService>#directoryService</directoryService>
> </dnsServer>
This transports configuration looks a bit chatty. A simpler solution
could be:
<...Server>
<transports>
<tcpTransport .../>
<udpTransport .../>
</transports>
</...Server>
Or
<...Server>
<tcpTransport .../>
<udpTransport .../>
</...Server>
Kind Regards,
Stefan