Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 31433 invoked from network); 13 Oct 2010 08:02:07 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 13 Oct 2010 08:02:07 -0000 Received: (qmail 5815 invoked by uid 500); 13 Oct 2010 08:02:06 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 5775 invoked by uid 500); 13 Oct 2010 08:02:04 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 5763 invoked by uid 99); 13 Oct 2010 08:02:03 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Oct 2010 08:02:03 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of pajbam@gmail.com designates 74.125.82.178 as permitted sender) Received: from [74.125.82.178] (HELO mail-wy0-f178.google.com) (74.125.82.178) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Oct 2010 08:01:55 +0000 Received: by wyb33 with SMTP id 33so567862wyb.37 for ; Wed, 13 Oct 2010 01:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:content-type :mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=Kd/9qpWHU8UnFSc0TwW7Cjch5e/wL4nwrYkr+fjmikw=; b=upxCxkSYRq8nBJJXwW8lxy7By/8WmVTBHeZ6MjbO4EyUBAjMp5Q4aB7EUFaiOVpGMl EoUc/Tflac2OwrnsboWx4/Zc5KIv/8SYYRs1gJ3ak9jXyylmjBBisHCJLmo3hpNY+2FV vequLBwMcmmZ3+q64/B6y+JEDhYSPXk7rfnl4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=q87UY4vsrTKR+gBiChGXLrSiNesiKaGVKJlaIzyYlQc/3F8G/hrR6XfEHlI0cigepk 20qcRXrZH4pRKEo3xz28B4YDBFcC5YDZ1gaJ27y0igAIc0+658C0EpCiCAl8FI0rbTGu TS2UK1Vv3ltRvPoZQkpCQgUuTWhvlWY0ZNfLA= Received: by 10.227.145.69 with SMTP id c5mr8104492wbv.168.1286956894955; Wed, 13 Oct 2010 01:01:34 -0700 (PDT) Received: from [10.0.1.2] (def92-4-82-225-58-213.fbx.proxad.net [82.225.58.213]) by mx.google.com with ESMTPS id o43sm2928689weq.23.2010.10.13.01.01.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 13 Oct 2010 01:01:33 -0700 (PDT) Sender: Pierre-Arnaud Marcelot Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: Question about the configuration layout From: Pierre-Arnaud Marcelot In-Reply-To: Date: Wed, 13 Oct 2010 10:01:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0D35E7B1-3004-4C09-9906-33211D7EB533@marcelot.net> References: <4CB50001.5010700@gmail.com> To: "Apache Directory Developers List" X-Mailer: Apple Mail (2.1081) X-Virus-Checked: Checked by ClamAV on apache.org Hi, On 13 oct. 2010, at 09:22, Kiran Ayyagari wrote: > On Wed, Oct 13, 2010 at 6:10 AM, Emmanuel Lecharny = wrote: >> Hi guys, >>=20 >> 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) >=20 > 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).=20 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=3Ddefault,ou=3Dconfig >=20 > the way we find where the DS is configured is search for > (ads-directoryServiceId=3Ddefault) > 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 >>=20 >> 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 : >>=20 >> *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. >>=20 >> 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 >>=20 >> Thoughts ? >>=20 >> A[ads-base] >> m-may: description >> m-may: ads-enabled >>=20 >> 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) >>=20 >> ads-dsChangeLog --> ads-base >> m-may: ads-changeLogEnabled >> m-may: ads-changeLogExposed >>=20 >> ads-dsJournal --> ads-base >> m-must: ads-journalFileName >> m-may: ads-journalWorkingDir >> m-may: ads-journalRotation >> m-may: ads-journalEnabled >>=20 >> ads-interceptor --> ads-base >> m-must: ads-interceptorId >> m-must: ads-interceptorOrder >> m-must: ads-interceptorClassName >>=20 >> A[ads-partition] --> ads-base >> m-must: ads-partitionId >> m-must: ads-partitionSuffix >> m-may: ads-partitionSyncOnWrite >>=20 >> ads-jdbmPartition --> ads-partition >> m-may: ads-partitionCacheSize >> m-may: ads-jdbmPartitionOptimizerEnabled >> m-may: ads-jdbmIndexes* : distinguishedName (points to = ads-jdbmIndex) >>=20 >> A[ads-index] --> ads-base >> m-must: ads-indexAttributeId >>=20 >> ads-jdbmIndex --> ads-index >> m-may: ads-indexFileName >> m-may: ads-indexWorkingDir >> m-may: ads-indexNumDupLimit >> m-may: ads-indexCacheSize >>=20 >> 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 >>=20 >> ads-tcpTransport --> ads-transport >>=20 >> ads-udpTransport --> ads-transport >>=20 >> A[ads-server] --> ads-base >> m-must: ads-serverId >> m-must: ads-transports* : distinguishedName (points to = ads-transport) >>=20 >> A[ads-catalogBasedServer] --> ads-server >> m-may: ads-serverDS >> m-may: ads-searchBaseDN >>=20 >> 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) >>=20 >> 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 >>=20 >> ads-dnsServer --> ads-catalogBasedServer >>=20 >> ads-dhcpServer --> ads-catalogBasedServer >>=20 >> ads-ntpServer --> ads-server >>=20 >> 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 >>=20 >> ads-ldapServerSaslMechanismHandler --> ads-base >> m-must: ads-ldapServerSaslMechName >> m-must: ads-ldapServerSaslMechClassName >> m-may: ads-ldapServerNtlmMechProvider >>=20 >> ads-ldapServerExtendedOpHandler --> ads-base >> m-must: ads-ldapServerExtendedOpHandlerClass >> m-must: ads-Id >>=20 >> ads-httpWebApp --> ads-base >> m-must: ads-httpWarFile >> m-must: ads-id >> m-may: ads-httpAppCtxPath >>=20 >> ads-httpServer --> ads-base >> m-must: ads-serverId >> m-may: ads-systemPort >> m-may: ads-httpConfFile >>=20 >> 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 >>=20 >> 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 >>=20 >> 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 >>=20 >> -- >> Regards, >> Cordialement, >> Emmanuel L=E9charny >> www.iktek.com >>=20 >>=20 >=20 > thanks Emmanuel >=20 > Kiran Ayyagari