directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot ...@marcelot.net>
Subject Re: Question about the configuration layout
Date Wed, 13 Oct 2010 08:01:31 GMT
Hi,

On 13 oct. 2010, at 09:22, Kiran Ayyagari wrote:

> On Wed, Oct 13, 2010 at 6:10 AM, Emmanuel Lecharny <elecharny@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


Mime
View raw message