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...@gmail.com> on 2010/10/13 02:40:33 UTC
Question about the configuration layout
Hi guys,
as I was writing the configuration documentation, based on the way we
initialize the server, I went through the objectClasses we use to define
the configuration for each element. That raised a question in my mind :
- why don't we link the elements together ?
Right now, we expect some code to put the glue between those elements
(ie teh LdapServer OC does not contain any AT defining the DS to use,
the DS does not contain the list of Partitions it uses, etc). Wouldn't
it be better to add some AT in each elements to completely define, say,
the LdapServer configuration from the LdapServer entry, following the
contained ATs ?
One more thing : we should probably define an Abstract ads-oc OC
containing the 'description' and 'ads-enabled' elements, which are
present in all the OCs ? I propose such an OC to handle those informations :
*A[ads-base]
m-may: description
m-may: ads-enabled
I have gathered all the existing OC with there MAY and MUST ATs, and
listed them here. The A[xxx] notation describes an ABSTRACT OC. The -->
notation defines a hierarchical relation between 2 OCs (ie OC2 --> OC1
means that OC1 is the SUP in OC2). The * notation means that we may have
from 0 to N distinguishedName in an AT. The ATs pointing to other ads
OCs are also noted.
With a little effort, I also think that reading such a hierarchy, we
could automatically generate the beans using introspection, instead of
writing a reader for each of those elements.
Thoughts ?
A[ads-base]
m-may: description
m-may: ads-enabled
ads-directoryService --> ads-base
m-must: ads-directoryServiceId
m-must: ads-dsReplicaId
m-may: ads-dsAccessControlEnabled
m-may: ads-dsAllowAnonymousAccess
m-may: ads-dsChangeLog : distinguishedName (points to ads-dsChangeLog)
m-may: ads-dsDenormalizeOpAttrsEnabled
m-may: ads-dsJournal : distinguishedName (points to ads-dsJournal)
m-may: ads-dsMaxPDUSize
m-may: ads-dsPasswordHidden
m-may: ads-dsReplication : distinguishedName (points to
ads-dsReplication)
m-may: ads-dsSyncPeriodMillis
m-may: ads-dsTestEntries
m-must: ads-interceptors* : distinguishedName (points to ads-interceptor)
m-must: ads-systemPartition : distinguishedName (points to ads-partition)
m-may: ads-partitions* : distinguishedName (points to ads-partition)
m-may: ads-replicationProvider : distinguishedName (points to
ads-replProvider)
m-may: ads-replicationConsumer : distinguishedName (points to
ads-replConsumer)
m-may: ads-passwordPolicy : distinguishedName (points to pwdPolicy)
ads-dsChangeLog --> ads-base
m-may: ads-changeLogEnabled
m-may: ads-changeLogExposed
ads-dsJournal --> ads-base
m-must: ads-journalFileName
m-may: ads-journalWorkingDir
m-may: ads-journalRotation
m-may: ads-journalEnabled
ads-interceptor --> ads-base
m-must: ads-interceptorId
m-must: ads-interceptorOrder
m-must: ads-interceptorClassName
A[ads-partition] --> ads-base
m-must: ads-partitionId
m-must: ads-partitionSuffix
m-may: ads-partitionSyncOnWrite
ads-jdbmPartition --> ads-partition
m-may: ads-partitionCacheSize
m-may: ads-jdbmPartitionOptimizerEnabled
m-may: ads-jdbmIndexes* : distinguishedName (points to ads-jdbmIndex)
A[ads-index] --> ads-base
m-must: ads-indexAttributeId
ads-jdbmIndex --> ads-index
m-may: ads-indexFileName
m-may: ads-indexWorkingDir
m-may: ads-indexNumDupLimit
m-may: ads-indexCacheSize
A[ads-transport] --> ads-base
m-must: ads-transportId
m-must: ads-systemPort
m-may: ads-transportAddress
m-may: ads-transportBacklog
m-may: ads-transportEnableSSL
m-may: ads-transportNbThreads
ads-tcpTransport --> ads-transport
ads-udpTransport --> ads-transport
A[ads-server] --> ads-base
m-must: ads-serverId
m-must: ads-transports* : distinguishedName (points to ads-transport)
A[ads-catalogBasedServer] --> ads-server
m-may: ads-serverDS
m-may: ads-searchBaseDN
ads-ldapServer --> ads-catalogBasedServer
m-may: ads-ldapServerConfidentialityRequired
m-may: ads-ldapServerMaxSizeLimit
m-may: ads-ldapServerMaxTimeLimit
m-may: ads-ldapServerSaslHost
m-may: ads-ldapServerSaslPrincipal
m-may: ads-ldapServerSaslRealms
m-may: ads-ldapServerKeystoreFile
m-may: ads-ldapServerCertificatePassword
m-may: ads-replProviderImpl
m-may: ads-enableReplProvider
m-may: ads-saslMechHandlers* : distinguishedName (points to
ads-ldapServerSaslMechanismHandler)
m-may: ads-extendedOps* : distingushedName (points to
ads-ldapServerExtendedOpHandler)
ads-kerberosServer --> ads-catalogBasedServer
m-may: ads-krbAllowableClockSkew
m-may: ads-krbEncryptionTypes
m-may: ads-krbEmptyAddressesAllowed
m-may: ads-krbForwardableAllowed
m-may: ads-krbPaEncTimestampRequired
m-may: ads-krbPostdatedAllowed
m-may: ads-krbProxiableAllowed
m-may: ads-krbRenewableAllowed
m-may: ads-krbKdcPrincipal
m-may: ads-krbMaximumRenewableLifetime
m-may: ads-krbMaximumTicketLifetime
m-may: ads-krbPrimaryRealm
m-may: ads-krbBodyChecksumVerified
ads-dnsServer --> ads-catalogBasedServer
ads-dhcpServer --> ads-catalogBasedServer
ads-ntpServer --> ads-server
ads-changePasswordServer --> ads-catalogBasedServer
m-may: ads-krbAllowableClockSkew
m-may: ads-krbEmptyAddressesAllowed
m-may: ads-krbEncryptionTypes
m-may: ads-krbPrimaryRealm
m-may: ads-chgPwdPolicyCategoryCount
m-may: ads-chgPwdPolicyPasswordLength
m-may: ads-chgPwdPolicyTokenSize
m-may: ads-chgPwdServicePrincipal
ads-ldapServerSaslMechanismHandler --> ads-base
m-must: ads-ldapServerSaslMechName
m-must: ads-ldapServerSaslMechClassName
m-may: ads-ldapServerNtlmMechProvider
ads-ldapServerExtendedOpHandler --> ads-base
m-must: ads-ldapServerExtendedOpHandlerClass
m-must: ads-Id
ads-httpWebApp --> ads-base
m-must: ads-httpWarFile
m-must: ads-id
m-may: ads-httpAppCtxPath
ads-httpServer --> ads-base
m-must: ads-serverId
m-may: ads-systemPort
m-may: ads-httpConfFile
ads-replConsumer --> ads-base
m-must: ads-dsReplicaId
m-must: ads-replAliasDerefMode
m-must: ads-searchBaseDN
m-must: ads-replLastSentCsn
m-must: ads-replSearchScope
m-must: ads-replSearchFilter
m-may: ads-replRefreshNPersist
m-may: ads-replUseTls
m-may: ads-replStrictCertValidation
m-may: ads-replPeerCertificate
ads-replProvider --> ads-base
m-must: ads-dsReplicaId
m-must: ads-searchBaseDN
m-must: ads-replProvHostName
m-may: ads-replAliasDerefMode
m-may: ads-replAttribute
m-may: ads-replProvPort
m-may: ads-replRefreshInterval
m-may: ads-replRefreshNPersist
m-may: ads-replSearchScope
m-may: ads-replSearchFilter
m-may: ads-replSearchSizeLimit
m-may: ads-replSearchTimeOut
m-may: ads-replUserDn
m-may: ads-replUserPassword
m-may: ads-replCookie
pwdPolicy --> ads-base
m-must: pwdAttribute
m-may: pwdMinAge
m-may: pwdMaxAge
m-may: pwdInHistory
m-may: pwdCheckQuality
m-may: pwdMinLength
m-may: pwdMaxLength
m-may: pwdExpireWarning
m-may: pwdGraceAuthNLimit
m-may: pwdGraceExpire
m-may: pwdLockout
m-may: pwdLockoutDuration
m-may: pwdMaxFailure
m-may: pwdFailureCountInterval
m-may: pwdMustChange
m-may: pwdAllowUserChange
m-may: pwdSafeModify
m-may: pwdMinDelay
m-may: pwdMaxDelay
m-may: pwdMaxIdle
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Question about the configuration layout
Posted by Stefan Seelmann <se...@apache.org>.
Hi Emmanuel,
On Wed, Oct 13, 2010 at 2:40 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi guys,
>
> as I was writing the configuration documentation, based on the way we
> initialize the server, I went through the objectClasses we use to define the
> configuration for each element. That raised a question in my mind :
> - why don't we link the elements together ?
>
> Right now, we expect some code to put the glue between those elements (ie
> teh LdapServer OC does not contain any AT defining the DS to use, the DS
> does not contain the list of Partitions it uses, etc). Wouldn't it be better
> to add some AT in each elements to completely define, say, the LdapServer
> configuration from the LdapServer entry, following the contained ATs ?
I'd say it depends on the kind of relationship of those elements.
If the relationship is a composition (i.e. the nested element can't
live without the wrapping element) then we should use a hierarchical
mapping. In that case an attribute in the parent entry that contains a
DN pointing to the child entry should be avoided because of duplicate
information.
> One more thing : we should probably define an Abstract ads-oc OC containing
> the 'description' and 'ads-enabled' elements, which are present in all the
> OCs ? I propose such an OC to handle those informations :
>
> *A[ads-base]
> m-may: description
> m-may: ads-enabled
+1
> I have gathered all the existing OC with there MAY and MUST ATs, and listed
> them here. The A[xxx] notation describes an ABSTRACT OC. The --> notation
> defines a hierarchical relation between 2 OCs (ie OC2 --> OC1 means that OC1
> is the SUP in OC2). The * notation means that we may have from 0 to N
> distinguishedName in an AT. The ATs pointing to other ads OCs are also
> noted.
>
> With a little effort, I also think that reading such a hierarchy, we could
> automatically generate the beans using introspection, instead of writing a
> reader for each of those elements.
My idea here was to use a persistence framework, like DataNucleus that
is an JDO implementation. But I guess that's not so easy because when
reading the config we only have the raw partition.
Kind Regards,
Stefan
Re: Question about the configuration layout
Posted by Kiran Ayyagari <ka...@apache.org>.
On Wed, Oct 13, 2010 at 1:47 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> On 10/13/10 9:22 AM, Kiran Ayyagari wrote:
>>
>> On Wed, Oct 13, 2010 at 6:10 AM, Emmanuel Lecharny<el...@gmail.com>
>> wrote:
>>>
>>> Hi guys,
>>>
>>> as I was writing the configuration documentation, based on the way we
>>> initialize the server, I went through the objectClasses we use to define
>>> the
>>> configuration for each element. That raised a question in my mind :
>>> - why don't we link the elements together ?
>>
>> to simply put it it makes creating any new configuration element
>> a bottom-up approach rather than top-down, for ex.
>> to configure an LdapServer instance, the user needs to define
>> its containments like transports, extended handlers and sasl mechanisms
>> first
>> and then take these DNs and add them to the LdapServer config entry for
>> linking.
>> (the other approch is to add some non-existing DNs first and later remove
>> it)
>
> You aren't forced to define any of the containments if you don't want to.
> Just put nothing in the DN referencing sub-elements.
then let us void this feature to link DNs, they will be abused by
users the day they realize that
this is allowed
>
> The thing is that in order to have a LDAPServer working, you *have* to
> define all the sub-elements anyway...
>>
>> IMHO, I find this really complex, OTOH using this 'linking option'
>> user *might* spread
>> the config across the partition instead of under a single container
>
> I see your point. But the pointers may also help to grab the entries (no
> need to do a search, a lookup will be just enough). Plus note that DSR (once
> we have implemented it) may force the elements to be stored one level under
> their container. At least, this would be explicit, instead of being coded.
>
>>> Right now, we expect some code to put the glue between those elements (ie
>>> teh LdapServer OC does not contain any AT defining the DS to use, the DS
>>> does not contain the list of Partitions it uses, etc).
>>
>> I would see it this way, it actually enforces a configuration policy that
>> any configurable container(e.x DS, LdapServer etc) object's
>> configuration should be present
>> *in* and *under* the associated container ldap entry
>> so all the configuration related to DS will be in and under the entry with
>> DN
>> ads-directoryServiceId=default,ou=config
>>
>> the way we find where the DS is configured is search for
>> (ads-directoryServiceId=default)
>> at ONE level scope and we know that the entire configuration related
>> to DS is present
>> in and under this returned entry
>
> DSR is the way to go, IMO. But maybe we don't need the links. It 's just
> that we may be able to generate the accessor automatically from the entries
> if we have the links, when we have to do that by hand without them.
>
>>> Wouldn't it be better
>>> to add some AT in each elements to completely define, say, the LdapServer
>>> configuration from the LdapServer entry, following the contained ATs ?
>>
>> IMHO, I don't think so
>
> Better, not better, I would say easier instead. Again, from the code
> generation of the accessors POV.
>>>
>>> One more thing : we should probably define an Abstract ads-oc OC
>>> containing
>>> the 'description' and 'ads-enabled' elements, which are present in all
>>> the
>>> OCs ? I propose such an OC to handle those informations :
>>>
>>> *A[ads-base]
>>> m-may: description
>>> m-may: ads-enabled
>>
>> +1, this will really make the config more concise and we can add other
>> common ATs that
>> we are talking about like 'comment' that will allow users to add some
>> comments in the config
>> elements
>
> I will add this guy.
>>>
>>> I have gathered all the existing OC with there MAY and MUST ATs, and
>>> listed
>>> them here. The A[xxx] notation describes an ABSTRACT OC. The -->
>>> notation
>>> defines a hierarchical relation between 2 OCs (ie OC2 --> OC1 means that
>>> OC1
>>> is the SUP in OC2). The * notation means that we may have from 0 to N
>>> distinguishedName in an AT. The ATs pointing to other ads OCs are also
>>> noted.
>>>
>>> With a little effort, I also think that reading such a hierarchy, we
>>> could
>>> automatically generate the beans using introspection, instead of writing
>>> a
>>> reader for each of those elements.
>>
>> didn't understand completely, but, we need a reader to instantiate the
>> beans
>> and we can also introspect based on the OCs and hierarchy rather than
>> the linked ATs
>
> Using the OCs, we can generate the Beans (we would need a maven plugin for
> that, not sure it's usefull...) and the reader (probably more useful).
>
> I would at least say that we should let the reader instanciates the beans
> associated with each Entry automatically using introspection. For instance,
> the OC ads-base will be associate with an AdsBase java class, containing two
> fields :
> - String description
> - boolean adsEnabled
>
> when we read an Entry which has the ads-base SUP OC, we can call the setter
> for those both fields using the MAY or MUST name :
> - may: ads-enabled -> setAdsEnabled()
> - may: description -> setDescription()
>
> Then you don't need to write readXXX( DN ) methods at all, this can be
> completely automatic.
hmmm, but how do we perform more strict (hence user friendly) validations if
we generate the code, we need to know each specific bean type and what
do we need to do, no?
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
Kiran Ayyagari
Re: Question about the configuration layout
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 10/13/10 9:22 AM, Kiran Ayyagari wrote:
> On Wed, Oct 13, 2010 at 6:10 AM, Emmanuel Lecharny<el...@gmail.com> wrote:
>> Hi guys,
>>
>> as I was writing the configuration documentation, based on the way we
>> initialize the server, I went through the objectClasses we use to define the
>> configuration for each element. That raised a question in my mind :
>> - why don't we link the elements together ?
> to simply put it it makes creating any new configuration element
> a bottom-up approach rather than top-down, for ex.
> to configure an LdapServer instance, the user needs to define
> its containments like transports, extended handlers and sasl mechanisms first
> and then take these DNs and add them to the LdapServer config entry for linking.
> (the other approch is to add some non-existing DNs first and later remove it)
You aren't forced to define any of the containments if you don't want
to. Just put nothing in the DN referencing sub-elements.
The thing is that in order to have a LDAPServer working, you *have* to
define all the sub-elements anyway...
> IMHO, I find this really complex, OTOH using this 'linking option'
> user *might* spread
> the config across the partition instead of under a single container
I see your point. But the pointers may also help to grab the entries (no
need to do a search, a lookup will be just enough). Plus note that DSR
(once we have implemented it) may force the elements to be stored one
level under their container. At least, this would be explicit, instead
of being coded.
>> Right now, we expect some code to put the glue between those elements (ie
>> teh LdapServer OC does not contain any AT defining the DS to use, the DS
>> does not contain the list of Partitions it uses, etc).
> I would see it this way, it actually enforces a configuration policy that
> any configurable container(e.x DS, LdapServer etc) object's
> configuration should be present
> *in* and *under* the associated container ldap entry
> so all the configuration related to DS will be in and under the entry with DN
> ads-directoryServiceId=default,ou=config
>
> the way we find where the DS is configured is search for
> (ads-directoryServiceId=default)
> at ONE level scope and we know that the entire configuration related
> to DS is present
> in and under this returned entry
DSR is the way to go, IMO. But maybe we don't need the links. It 's just
that we may be able to generate the accessor automatically from the
entries if we have the links, when we have to do that by hand without them.
>> Wouldn't it be better
>> to add some AT in each elements to completely define, say, the LdapServer
>> configuration from the LdapServer entry, following the contained ATs ?
> IMHO, I don't think so
Better, not better, I would say easier instead. Again, from the code
generation of the accessors POV.
>> One more thing : we should probably define an Abstract ads-oc OC containing
>> the 'description' and 'ads-enabled' elements, which are present in all the
>> OCs ? I propose such an OC to handle those informations :
>>
>> *A[ads-base]
>> m-may: description
>> m-may: ads-enabled
> +1, this will really make the config more concise and we can add other
> common ATs that
> we are talking about like 'comment' that will allow users to add some
> comments in the config
> elements
I will add this guy.
>> I have gathered all the existing OC with there MAY and MUST ATs, and listed
>> them here. The A[xxx] notation describes an ABSTRACT OC. The --> notation
>> defines a hierarchical relation between 2 OCs (ie OC2 --> OC1 means that OC1
>> is the SUP in OC2). The * notation means that we may have from 0 to N
>> distinguishedName in an AT. The ATs pointing to other ads OCs are also
>> noted.
>>
>> With a little effort, I also think that reading such a hierarchy, we could
>> automatically generate the beans using introspection, instead of writing a
>> reader for each of those elements.
> didn't understand completely, but, we need a reader to instantiate the beans
> and we can also introspect based on the OCs and hierarchy rather than
> the linked ATs
Using the OCs, we can generate the Beans (we would need a maven plugin
for that, not sure it's usefull...) and the reader (probably more useful).
I would at least say that we should let the reader instanciates the
beans associated with each Entry automatically using introspection. For
instance, the OC ads-base will be associate with an AdsBase java class,
containing two fields :
- String description
- boolean adsEnabled
when we read an Entry which has the ads-base SUP OC, we can call the
setter for those both fields using the MAY or MUST name :
- may: ads-enabled -> setAdsEnabled()
- may: description -> setDescription()
Then you don't need to write readXXX( DN ) methods at all, this can be
completely automatic.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Question about the configuration layout
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi,
On 13 oct. 2010, at 09:22, Kiran Ayyagari wrote:
> On Wed, Oct 13, 2010 at 6:10 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
>> Hi guys,
>>
>> as I was writing the configuration documentation, based on the way we
>> initialize the server, I went through the objectClasses we use to define the
>> configuration for each element. That raised a question in my mind :
>> - why don't we link the elements together ?
> to simply put it it makes creating any new configuration element
> a bottom-up approach rather than top-down, for ex.
> to configure an LdapServer instance, the user needs to define
> its containments like transports, extended handlers and sasl mechanisms first
> and then take these DNs and add them to the LdapServer config entry for linking.
> (the other approch is to add some non-existing DNs first and later remove it)
>
> IMHO, I find this really complex, OTOH using this 'linking option'
> user *might* spread
> the config across the partition instead of under a single container
I really agree with Kiran on that point, even though, from a technical POV, it would be very handy to have all objects linked from the top.
Adding these links requires extra steps for a user when editing the configuration by end, which is already not very easy due to the large size of the LDIF file (it would require to go back and forth between various entries in the file).
Now, if we consider the configuration will be mostly edited by a tool, that's another story...
If we provide the tools that makes editing easy, we can probably make the format a little more complex because most uses won't see it, and only the most skilled ones will edit the file by hand.
>> Right now, we expect some code to put the glue between those elements (ie
>> teh LdapServer OC does not contain any AT defining the DS to use, the DS
>> does not contain the list of Partitions it uses, etc).
> I would see it this way, it actually enforces a configuration policy that
> any configurable container(e.x DS, LdapServer etc) object's
> configuration should be present
> *in* and *under* the associated container ldap entry
> so all the configuration related to DS will be in and under the entry with DN
> ads-directoryServiceId=default,ou=config
>
> the way we find where the DS is configured is search for
> (ads-directoryServiceId=default)
> at ONE level scope and we know that the entire configuration related
> to DS is present
> in and under this returned entry
+1
>> Wouldn't it be better
>> to add some AT in each elements to completely define, say, the LdapServer
>> configuration from the LdapServer entry, following the contained ATs ?
> IMHO, I don't think so
>>
>> One more thing : we should probably define an Abstract ads-oc OC containing
>> the 'description' and 'ads-enabled' elements, which are present in all the
>> OCs ? I propose such an OC to handle those informations :
>>
>> *A[ads-base]
>> m-may: description
>> m-may: ads-enabled
> +1, this will really make the config more concise and we can add other
> common ATs that
> we are talking about like 'comment' that will allow users to add some
> comments in the config
> elements
+1
>> I have gathered all the existing OC with there MAY and MUST ATs, and listed
>> them here. The A[xxx] notation describes an ABSTRACT OC. The --> notation
>> defines a hierarchical relation between 2 OCs (ie OC2 --> OC1 means that OC1
>> is the SUP in OC2). The * notation means that we may have from 0 to N
>> distinguishedName in an AT. The ATs pointing to other ads OCs are also
>> noted.
>>
>> With a little effort, I also think that reading such a hierarchy, we could
>> automatically generate the beans using introspection, instead of writing a
>> reader for each of those elements.
> didn't understand completely, but, we need a reader to instantiate the beans
> and we can also introspect based on the OCs and hierarchy rather than
> the linked ATs
Not only do we need a reader, but we also need a writer that would take config beans and turn them into the ldif file.
Speaking of config beans, I really think we need a general container bean for the whole configuration, say 'ApacheDsConfiguration'.
This object will contain references to other configuration sub-elements.
That's the bean we would get when reading the configuration from the ConfigurationReader class:
public static ApacheDsConfiguration readConfiguration( File file );
That's also the bean we would pass to the ConfigurationWriter to create the LDIF file:
public void writeConfiguration( ApacheDsConfiguration configuration, File file);
My 2 cents,
Pierre-Arnaud
>>
>> Thoughts ?
>>
>> A[ads-base]
>> m-may: description
>> m-may: ads-enabled
>>
>> ads-directoryService --> ads-base
>> m-must: ads-directoryServiceId
>> m-must: ads-dsReplicaId
>> m-may: ads-dsAccessControlEnabled
>> m-may: ads-dsAllowAnonymousAccess
>> m-may: ads-dsChangeLog : distinguishedName (points to ads-dsChangeLog)
>> m-may: ads-dsDenormalizeOpAttrsEnabled
>> m-may: ads-dsJournal : distinguishedName (points to ads-dsJournal)
>> m-may: ads-dsMaxPDUSize
>> m-may: ads-dsPasswordHidden
>> m-may: ads-dsReplication : distinguishedName (points to ads-dsReplication)
>> m-may: ads-dsSyncPeriodMillis
>> m-may: ads-dsTestEntries
>> m-must: ads-interceptors* : distinguishedName (points to ads-interceptor)
>> m-must: ads-systemPartition : distinguishedName (points to ads-partition)
>> m-may: ads-partitions* : distinguishedName (points to ads-partition)
>> m-may: ads-replicationProvider : distinguishedName (points to
>> ads-replProvider)
>> m-may: ads-replicationConsumer : distinguishedName (points to
>> ads-replConsumer)
>> m-may: ads-passwordPolicy : distinguishedName (points to pwdPolicy)
>>
>> ads-dsChangeLog --> ads-base
>> m-may: ads-changeLogEnabled
>> m-may: ads-changeLogExposed
>>
>> ads-dsJournal --> ads-base
>> m-must: ads-journalFileName
>> m-may: ads-journalWorkingDir
>> m-may: ads-journalRotation
>> m-may: ads-journalEnabled
>>
>> ads-interceptor --> ads-base
>> m-must: ads-interceptorId
>> m-must: ads-interceptorOrder
>> m-must: ads-interceptorClassName
>>
>> A[ads-partition] --> ads-base
>> m-must: ads-partitionId
>> m-must: ads-partitionSuffix
>> m-may: ads-partitionSyncOnWrite
>>
>> ads-jdbmPartition --> ads-partition
>> m-may: ads-partitionCacheSize
>> m-may: ads-jdbmPartitionOptimizerEnabled
>> m-may: ads-jdbmIndexes* : distinguishedName (points to ads-jdbmIndex)
>>
>> A[ads-index] --> ads-base
>> m-must: ads-indexAttributeId
>>
>> ads-jdbmIndex --> ads-index
>> m-may: ads-indexFileName
>> m-may: ads-indexWorkingDir
>> m-may: ads-indexNumDupLimit
>> m-may: ads-indexCacheSize
>>
>> A[ads-transport] --> ads-base
>> m-must: ads-transportId
>> m-must: ads-systemPort
>> m-may: ads-transportAddress
>> m-may: ads-transportBacklog
>> m-may: ads-transportEnableSSL
>> m-may: ads-transportNbThreads
>>
>> ads-tcpTransport --> ads-transport
>>
>> ads-udpTransport --> ads-transport
>>
>> A[ads-server] --> ads-base
>> m-must: ads-serverId
>> m-must: ads-transports* : distinguishedName (points to ads-transport)
>>
>> A[ads-catalogBasedServer] --> ads-server
>> m-may: ads-serverDS
>> m-may: ads-searchBaseDN
>>
>> ads-ldapServer --> ads-catalogBasedServer
>> m-may: ads-ldapServerConfidentialityRequired
>> m-may: ads-ldapServerMaxSizeLimit
>> m-may: ads-ldapServerMaxTimeLimit
>> m-may: ads-ldapServerSaslHost
>> m-may: ads-ldapServerSaslPrincipal
>> m-may: ads-ldapServerSaslRealms
>> m-may: ads-ldapServerKeystoreFile
>> m-may: ads-ldapServerCertificatePassword
>> m-may: ads-replProviderImpl
>> m-may: ads-enableReplProvider
>> m-may: ads-saslMechHandlers* : distinguishedName (points to
>> ads-ldapServerSaslMechanismHandler)
>> m-may: ads-extendedOps* : distingushedName (points to
>> ads-ldapServerExtendedOpHandler)
>>
>> ads-kerberosServer --> ads-catalogBasedServer
>> m-may: ads-krbAllowableClockSkew
>> m-may: ads-krbEncryptionTypes
>> m-may: ads-krbEmptyAddressesAllowed
>> m-may: ads-krbForwardableAllowed
>> m-may: ads-krbPaEncTimestampRequired
>> m-may: ads-krbPostdatedAllowed
>> m-may: ads-krbProxiableAllowed
>> m-may: ads-krbRenewableAllowed
>> m-may: ads-krbKdcPrincipal
>> m-may: ads-krbMaximumRenewableLifetime
>> m-may: ads-krbMaximumTicketLifetime
>> m-may: ads-krbPrimaryRealm
>> m-may: ads-krbBodyChecksumVerified
>>
>> ads-dnsServer --> ads-catalogBasedServer
>>
>> ads-dhcpServer --> ads-catalogBasedServer
>>
>> ads-ntpServer --> ads-server
>>
>> ads-changePasswordServer --> ads-catalogBasedServer
>> m-may: ads-krbAllowableClockSkew
>> m-may: ads-krbEmptyAddressesAllowed
>> m-may: ads-krbEncryptionTypes
>> m-may: ads-krbPrimaryRealm
>> m-may: ads-chgPwdPolicyCategoryCount
>> m-may: ads-chgPwdPolicyPasswordLength
>> m-may: ads-chgPwdPolicyTokenSize
>> m-may: ads-chgPwdServicePrincipal
>>
>> ads-ldapServerSaslMechanismHandler --> ads-base
>> m-must: ads-ldapServerSaslMechName
>> m-must: ads-ldapServerSaslMechClassName
>> m-may: ads-ldapServerNtlmMechProvider
>>
>> ads-ldapServerExtendedOpHandler --> ads-base
>> m-must: ads-ldapServerExtendedOpHandlerClass
>> m-must: ads-Id
>>
>> ads-httpWebApp --> ads-base
>> m-must: ads-httpWarFile
>> m-must: ads-id
>> m-may: ads-httpAppCtxPath
>>
>> ads-httpServer --> ads-base
>> m-must: ads-serverId
>> m-may: ads-systemPort
>> m-may: ads-httpConfFile
>>
>> ads-replConsumer --> ads-base
>> m-must: ads-dsReplicaId
>> m-must: ads-replAliasDerefMode
>> m-must: ads-searchBaseDN
>> m-must: ads-replLastSentCsn
>> m-must: ads-replSearchScope
>> m-must: ads-replSearchFilter
>> m-may: ads-replRefreshNPersist
>> m-may: ads-replUseTls
>> m-may: ads-replStrictCertValidation
>> m-may: ads-replPeerCertificate
>>
>> ads-replProvider --> ads-base
>> m-must: ads-dsReplicaId
>> m-must: ads-searchBaseDN
>> m-must: ads-replProvHostName
>> m-may: ads-replAliasDerefMode
>> m-may: ads-replAttribute
>> m-may: ads-replProvPort
>> m-may: ads-replRefreshInterval
>> m-may: ads-replRefreshNPersist
>> m-may: ads-replSearchScope
>> m-may: ads-replSearchFilter
>> m-may: ads-replSearchSizeLimit
>> m-may: ads-replSearchTimeOut
>> m-may: ads-replUserDn
>> m-may: ads-replUserPassword
>> m-may: ads-replCookie
>>
>> pwdPolicy --> ads-base
>> m-must: pwdAttribute
>> m-may: pwdMinAge
>> m-may: pwdMaxAge
>> m-may: pwdInHistory
>> m-may: pwdCheckQuality
>> m-may: pwdMinLength
>> m-may: pwdMaxLength
>> m-may: pwdExpireWarning
>> m-may: pwdGraceAuthNLimit
>> m-may: pwdGraceExpire
>> m-may: pwdLockout
>> m-may: pwdLockoutDuration
>> m-may: pwdMaxFailure
>> m-may: pwdFailureCountInterval
>> m-may: pwdMustChange
>> m-may: pwdAllowUserChange
>> m-may: pwdSafeModify
>> m-may: pwdMinDelay
>> m-may: pwdMaxDelay
>> m-may: pwdMaxIdle
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
>>
>
> thanks Emmanuel
>
> Kiran Ayyagari
Re: Question about the configuration layout
Posted by Kiran Ayyagari <ka...@apache.org>.
On Wed, Oct 13, 2010 at 6:10 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi guys,
>
> as I was writing the configuration documentation, based on the way we
> initialize the server, I went through the objectClasses we use to define the
> configuration for each element. That raised a question in my mind :
> - why don't we link the elements together ?
to simply put it it makes creating any new configuration element
a bottom-up approach rather than top-down, for ex.
to configure an LdapServer instance, the user needs to define
its containments like transports, extended handlers and sasl mechanisms first
and then take these DNs and add them to the LdapServer config entry for linking.
(the other approch is to add some non-existing DNs first and later remove it)
IMHO, I find this really complex, OTOH using this 'linking option'
user *might* spread
the config across the partition instead of under a single container
>
> Right now, we expect some code to put the glue between those elements (ie
> teh LdapServer OC does not contain any AT defining the DS to use, the DS
> does not contain the list of Partitions it uses, etc).
I would see it this way, it actually enforces a configuration policy that
any configurable container(e.x DS, LdapServer etc) object's
configuration should be present
*in* and *under* the associated container ldap entry
so all the configuration related to DS will be in and under the entry with DN
ads-directoryServiceId=default,ou=config
the way we find where the DS is configured is search for
(ads-directoryServiceId=default)
at ONE level scope and we know that the entire configuration related
to DS is present
in and under this returned entry
>Wouldn't it be better
> to add some AT in each elements to completely define, say, the LdapServer
> configuration from the LdapServer entry, following the contained ATs ?
IMHO, I don't think so
>
> One more thing : we should probably define an Abstract ads-oc OC containing
> the 'description' and 'ads-enabled' elements, which are present in all the
> OCs ? I propose such an OC to handle those informations :
>
> *A[ads-base]
> m-may: description
> m-may: ads-enabled
+1, this will really make the config more concise and we can add other
common ATs that
we are talking about like 'comment' that will allow users to add some
comments in the config
elements
>
> I have gathered all the existing OC with there MAY and MUST ATs, and listed
> them here. The A[xxx] notation describes an ABSTRACT OC. The --> notation
> defines a hierarchical relation between 2 OCs (ie OC2 --> OC1 means that OC1
> is the SUP in OC2). The * notation means that we may have from 0 to N
> distinguishedName in an AT. The ATs pointing to other ads OCs are also
> noted.
>
> With a little effort, I also think that reading such a hierarchy, we could
> automatically generate the beans using introspection, instead of writing a
> reader for each of those elements.
didn't understand completely, but, we need a reader to instantiate the beans
and we can also introspect based on the OCs and hierarchy rather than
the linked ATs
>
> Thoughts ?
>
> A[ads-base]
> m-may: description
> m-may: ads-enabled
>
> ads-directoryService --> ads-base
> m-must: ads-directoryServiceId
> m-must: ads-dsReplicaId
> m-may: ads-dsAccessControlEnabled
> m-may: ads-dsAllowAnonymousAccess
> m-may: ads-dsChangeLog : distinguishedName (points to ads-dsChangeLog)
> m-may: ads-dsDenormalizeOpAttrsEnabled
> m-may: ads-dsJournal : distinguishedName (points to ads-dsJournal)
> m-may: ads-dsMaxPDUSize
> m-may: ads-dsPasswordHidden
> m-may: ads-dsReplication : distinguishedName (points to ads-dsReplication)
> m-may: ads-dsSyncPeriodMillis
> m-may: ads-dsTestEntries
> m-must: ads-interceptors* : distinguishedName (points to ads-interceptor)
> m-must: ads-systemPartition : distinguishedName (points to ads-partition)
> m-may: ads-partitions* : distinguishedName (points to ads-partition)
> m-may: ads-replicationProvider : distinguishedName (points to
> ads-replProvider)
> m-may: ads-replicationConsumer : distinguishedName (points to
> ads-replConsumer)
> m-may: ads-passwordPolicy : distinguishedName (points to pwdPolicy)
>
> ads-dsChangeLog --> ads-base
> m-may: ads-changeLogEnabled
> m-may: ads-changeLogExposed
>
> ads-dsJournal --> ads-base
> m-must: ads-journalFileName
> m-may: ads-journalWorkingDir
> m-may: ads-journalRotation
> m-may: ads-journalEnabled
>
> ads-interceptor --> ads-base
> m-must: ads-interceptorId
> m-must: ads-interceptorOrder
> m-must: ads-interceptorClassName
>
> A[ads-partition] --> ads-base
> m-must: ads-partitionId
> m-must: ads-partitionSuffix
> m-may: ads-partitionSyncOnWrite
>
> ads-jdbmPartition --> ads-partition
> m-may: ads-partitionCacheSize
> m-may: ads-jdbmPartitionOptimizerEnabled
> m-may: ads-jdbmIndexes* : distinguishedName (points to ads-jdbmIndex)
>
> A[ads-index] --> ads-base
> m-must: ads-indexAttributeId
>
> ads-jdbmIndex --> ads-index
> m-may: ads-indexFileName
> m-may: ads-indexWorkingDir
> m-may: ads-indexNumDupLimit
> m-may: ads-indexCacheSize
>
> A[ads-transport] --> ads-base
> m-must: ads-transportId
> m-must: ads-systemPort
> m-may: ads-transportAddress
> m-may: ads-transportBacklog
> m-may: ads-transportEnableSSL
> m-may: ads-transportNbThreads
>
> ads-tcpTransport --> ads-transport
>
> ads-udpTransport --> ads-transport
>
> A[ads-server] --> ads-base
> m-must: ads-serverId
> m-must: ads-transports* : distinguishedName (points to ads-transport)
>
> A[ads-catalogBasedServer] --> ads-server
> m-may: ads-serverDS
> m-may: ads-searchBaseDN
>
> ads-ldapServer --> ads-catalogBasedServer
> m-may: ads-ldapServerConfidentialityRequired
> m-may: ads-ldapServerMaxSizeLimit
> m-may: ads-ldapServerMaxTimeLimit
> m-may: ads-ldapServerSaslHost
> m-may: ads-ldapServerSaslPrincipal
> m-may: ads-ldapServerSaslRealms
> m-may: ads-ldapServerKeystoreFile
> m-may: ads-ldapServerCertificatePassword
> m-may: ads-replProviderImpl
> m-may: ads-enableReplProvider
> m-may: ads-saslMechHandlers* : distinguishedName (points to
> ads-ldapServerSaslMechanismHandler)
> m-may: ads-extendedOps* : distingushedName (points to
> ads-ldapServerExtendedOpHandler)
>
> ads-kerberosServer --> ads-catalogBasedServer
> m-may: ads-krbAllowableClockSkew
> m-may: ads-krbEncryptionTypes
> m-may: ads-krbEmptyAddressesAllowed
> m-may: ads-krbForwardableAllowed
> m-may: ads-krbPaEncTimestampRequired
> m-may: ads-krbPostdatedAllowed
> m-may: ads-krbProxiableAllowed
> m-may: ads-krbRenewableAllowed
> m-may: ads-krbKdcPrincipal
> m-may: ads-krbMaximumRenewableLifetime
> m-may: ads-krbMaximumTicketLifetime
> m-may: ads-krbPrimaryRealm
> m-may: ads-krbBodyChecksumVerified
>
> ads-dnsServer --> ads-catalogBasedServer
>
> ads-dhcpServer --> ads-catalogBasedServer
>
> ads-ntpServer --> ads-server
>
> ads-changePasswordServer --> ads-catalogBasedServer
> m-may: ads-krbAllowableClockSkew
> m-may: ads-krbEmptyAddressesAllowed
> m-may: ads-krbEncryptionTypes
> m-may: ads-krbPrimaryRealm
> m-may: ads-chgPwdPolicyCategoryCount
> m-may: ads-chgPwdPolicyPasswordLength
> m-may: ads-chgPwdPolicyTokenSize
> m-may: ads-chgPwdServicePrincipal
>
> ads-ldapServerSaslMechanismHandler --> ads-base
> m-must: ads-ldapServerSaslMechName
> m-must: ads-ldapServerSaslMechClassName
> m-may: ads-ldapServerNtlmMechProvider
>
> ads-ldapServerExtendedOpHandler --> ads-base
> m-must: ads-ldapServerExtendedOpHandlerClass
> m-must: ads-Id
>
> ads-httpWebApp --> ads-base
> m-must: ads-httpWarFile
> m-must: ads-id
> m-may: ads-httpAppCtxPath
>
> ads-httpServer --> ads-base
> m-must: ads-serverId
> m-may: ads-systemPort
> m-may: ads-httpConfFile
>
> ads-replConsumer --> ads-base
> m-must: ads-dsReplicaId
> m-must: ads-replAliasDerefMode
> m-must: ads-searchBaseDN
> m-must: ads-replLastSentCsn
> m-must: ads-replSearchScope
> m-must: ads-replSearchFilter
> m-may: ads-replRefreshNPersist
> m-may: ads-replUseTls
> m-may: ads-replStrictCertValidation
> m-may: ads-replPeerCertificate
>
> ads-replProvider --> ads-base
> m-must: ads-dsReplicaId
> m-must: ads-searchBaseDN
> m-must: ads-replProvHostName
> m-may: ads-replAliasDerefMode
> m-may: ads-replAttribute
> m-may: ads-replProvPort
> m-may: ads-replRefreshInterval
> m-may: ads-replRefreshNPersist
> m-may: ads-replSearchScope
> m-may: ads-replSearchFilter
> m-may: ads-replSearchSizeLimit
> m-may: ads-replSearchTimeOut
> m-may: ads-replUserDn
> m-may: ads-replUserPassword
> m-may: ads-replCookie
>
> pwdPolicy --> ads-base
> m-must: pwdAttribute
> m-may: pwdMinAge
> m-may: pwdMaxAge
> m-may: pwdInHistory
> m-may: pwdCheckQuality
> m-may: pwdMinLength
> m-may: pwdMaxLength
> m-may: pwdExpireWarning
> m-may: pwdGraceAuthNLimit
> m-may: pwdGraceExpire
> m-may: pwdLockout
> m-may: pwdLockoutDuration
> m-may: pwdMaxFailure
> m-may: pwdFailureCountInterval
> m-may: pwdMustChange
> m-may: pwdAllowUserChange
> m-may: pwdSafeModify
> m-may: pwdMinDelay
> m-may: pwdMaxDelay
> m-may: pwdMaxIdle
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
thanks Emmanuel
Kiran Ayyagari